Re: [oc] Is OCIDEC (and other opencore-cores) ill-suited for FPGA's?

[Richard Herveille <richard@asics.ws>]

Thanks for stating this so clearly to everybody.

There are a couple of reasons why the design is as it is.
But as to answer you questions, reply to you comments:

1) Register for timing not affected by counter width.
Correct, currently the registers are fixed.
The OCIDEC is a 32bit core. All registers are 32bit. If you write a value to a 
register you are able to read the same value. Adjusting the register size 
based on a parameter/generic sounds plausible, and will be incorporated in 
the new version (which I am writing right now). The new version allows you to 
better tune the design to your needs, by selecting the parts you require. 
Registers will be added to/removed from the design based on your selection. 
Embedded SRAMS might be a waste then.

2) Strange counter implementation.
There's nothing strange about it. One is a simple up/down counter. One is a 
small statemachine that loads the counter (always used in down mode) and runs 
it once. The synthesizer reduces the code for the counter to a down counter 
only. I tested this with Leonardo and Synplicity. Both generate optimized 
counters, with the exact cell count I would expect.

3) 'Row of Counters': if you take a close look at the design you see that a 
number of counters run at the same time, or are being trigger by different 
signals (and yes some are cascaded).

4) The design is intended for ASIC and FPGA use

5) Funny, it synthesizes here. Maybe if you tell me what's wrong I can fix the 
problems. And no, it's not a Verilog2VHDL conversion. As you could have seen, 
there is no Verilog OCIDEC-3 core.

6) Note that I am currently developing a new version.

Richard

rherveille@opencores.org



> Having implemented the OCIDEC3 (IDE(ATA)-controller with PIO and DMA
> support) for Xilinx SpartanII I get an huge block which eats up more
> then 500 slices. This is a few times more than expected. Having a closer
> look on it, there are 2 design details responsible for that.
>
> 1) Register for timings are not affected by counter widht.
> Regardless the generic for the maximum counterwidth, the many
> registers for the timings are fixed in counter width (8bit?). There are
> a lot of wasted FF here. Even better area efficiency could be reached by
> using Embedded SRAM cells as register bank.
>
> 2) Strange counter implementation.
> This doesnt seem to have the same impact as the register width, but
> it,s used in other opencore desings too. Is there a reason for the FF
> consuming "row of runonce counters" architecture I'm not aware off?
> Let me explain:
>
>   a)The Synthesis tool (exemplar for me) doesnt realize any counter
>     in this design and therefore any optimized counter macro are missed.
>     This is due the description used for the upDown counter here. Better
>     is something which uses "counter <= counter + 1;" or so, instead of
>     dealing of dealing with carry in and carry out.
>   b)Actually  "run once" downcounters are used as basic elemenst for the
>     "run once" thing,the component up down counter is never used for
>     counting up. This is confusing.
>     Why not using a clearly written runonce counter as basic element?
>   c)For every duration to count a new counter is used. Why not restarting
>     the loadable counter or built "self loading counter?" All You needed
>     is  one FSM, (most states switched by "counter reaches zero"), one
> muxer (FSM states selects timings as load value for counter) and one
> counter(started by FSM or after reaching zero). This saves gates in FPGA.
> Perhaps OCIDEC was designed for ASIC's.
>
> BTW: The VHDL code of ocidec has syntax errors. Seems to be an untested
>       ouput of a Verilog2VHDL converter.
>
>
> Best regards
>
> Volker Urban

--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml