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

[Volker Urban <volker.urban@web.de>]

Richard Herveille wrote:
> Thanks for stating this so clearly to everybody.

I hope, I haven't been impolite. Let me know, if aontother style of 
discussion is prefered here.


> 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. 

I'm looking forward


> 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.

Sorry for calling Your code strange, but I looked twice to understand
the code (its close to an hardware implementation and therefore not
so good to find out the behaviour) and Leonardo failed completly to see
the counter here:
I used Leonardo and searched in exemplar.log for lines with
".. inferred counter .." or something, meaning that synthesize realized 
from VHDL description, that a counter is used here. I could not found 
such informations. I replaced the counters with my own VHDL code and 
leonardo was happy to built in counters here and built a smaller code. 
Unfortunally, my counters did not work in the same way as Yours. I will
try it again with a new release of OCIDEC. Perhaps the log files could 
be stored under CVS too, just to let everybody know which versions and 
options are to apply to get identically results.

> 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).

I thought about it, chain of counters or cascaded counters is a better 
term. I have no verilog license for modelsim here, so I did not simulate 
the core with the supplied testbench.

> 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.

In a few "IF" branches (2 IIRC) the keyword "then" was missed. I got the 
source 2 times, same errors. I will try it again and let You know.

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

I will be happy to analyze it. I will send You my results. If useful 
I'll send the logs for map,place and route too (Xilinx) to give other 
users an idea about area and fastest clock. (Sending to You means 
writing to this mailing list, except for long files (i.e. logs))

Best regards,

Volker

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