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

[Richard Herveille <richard@asics.ws>]

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

Nah, but it sounds so hard whereas many points can be explained.
Though bugs and typos SHOULD be reported (everybody makes mistakes), that's 
the idea of OpenCores; others benefit of the efforts you make.

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

Instead of different type of cores there will be one core that can be user 
configured (using a defines file for Verilog, and Generics for VHDL). This 
makes it a cleaner and more optimized solution I think. If you have any ideas 
let me know.

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

Leonardo only reports 'inferred counter' when it recognizes something like 
a <= a + 1;
It knows it needs to generate an optimized counter, and creates the logic to 
implement a ripple-carry counter.
The up-down counter in the design is an optimized up-down counter with 
carry-in and carry-out. Because it is already optimized Leonardo doesn't 
recognize the structure (and hence doesn't say it does), but Leonardo doesn't 
need to recognize it, as it is already optimized. 

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

Maybe that's where the additional code went :-)

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

Deuh, see what you mean. How could I miss that ??????

>
> > 6) Note that I am currently developing a new version.
>
> I will be happy to analyze it.

I hope you will.

Cheers,
Richard

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