[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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