Nibz processor @ 472 LEs (16 bit generic specified)

hi

second round of VHDL at http://nibz.googlecode.com . The processor is
generic word sized, so 10 bit and 12 bit are just as possible. Still
needs some alu optimization to reduce numbe of useless implied
latches. The ALU should be more efficient, will have to hand code it
in a later version.

Let me know of any feedback.

cheers
jacko

jacko

Third round vhdl up. Fixed IR->P assignment which added one LE to
design. ALU still to do proper. Will do over this coming week. I will
do it as a combinational process. Strange that as instruction decode
is combinational on IR, which has a synchrnous load, that thecompiler
infered latches on the ALU intermediates. I whould have expoectd these
to optimize out, as they are not in the process sensitivity list.

Any ideas on why this is so in Quartus II 8.0 no optimizations
selected, everything as out of the box.

cheers

jacko

jacko wrote:

> Any ideas on why this is so in Quartus II 8.0 no optimizations
> selected, everything as out of the box.

The code is the problem:

cd /evtfs/home/tres/vhdl/
vcom -2002 -quiet -work work nibz3.vhd
** Error: nibz3.vhd(250):
Case statement covers only 16 out of 6561 cases.
** Error: nibz3.vhd(359): VHDL Compiler exiting

Compilation exited abnormally with code 2 at Sat Aug 9 07:12:00

Mike Treseler

On 9 Aug, 15:14, Mike Treseler <mtrese...@gmail.com> wrote:
> jacko wrote:
> > Any ideas on why this is so in Quartus II 8.0 no optimizations
> > selected, everything as out of the box.
>
> The code is the problem:
>
> cd /evtfs/home/tres/vhdl/
> vcom -2002 -quiet -work work nibz3.vhd
> ** Error: nibz3.vhd(250):
> Case statement covers only 16 out of 6561 cases.
> ** Error: nibz3.vhd(359): VHDL Compiler exiting
>
> Compilation exited abnormally with code 2 at Sat Aug *9 07:12:00

strange that, quartus does compile, and infers some latches, this is
ok, but there are other latches infered which should not be. I have to
move the alu to a seperate process, and then see. This will remove
assignments to any intermediate expressions, out of the main
instruction decode case statement. So the compilier will not need to
see assignment to the intermediates in instructions which do not use
the alu. OK. just wanted to know.

entity called nibz1 even though file called nibz3, googlecode not
allowing same name for any two uploads.

jacko

jacko wrote:

> strange that, quartus does compile, and infers some latches, this is
> ok, but there are other latches inferred which should not be.

Quartus does the best that it can with the code
and issues a warning.

Latches are only inferred if an unclocked process is
used and one or more cases are not covered.

It *is* a problem because fpga latches are only safe
if excruciating timing constraints are applied in synthesis.

It is a waste of resources because
flops are free in an fpga design.

My preferred solution is to use clocked processes exclusively.

Good luck with your design.

-- Mike Treseler

Mike Treseler

Hi

I have optimized alu some. and fixed correct return address stacked.
It is now compiling at 301 LEs, but has a low fmax of 25MHz in C3
speed MAX II. Is there any way of forcing carry routing via VHDL or is
that a tool option?

cheers
jacko

jacko

"Mike Treseler" <> wrote in message
news:...
> jacko wrote:
>
> It *is* a problem because fpga latches are only safe
> if excruciating timing constraints are applied in synthesis.
>

I'll strongly second Mike's advice and I'd go further and state that latches
are never safe unless
- The device actually has a hardware latch as a resource (unlikely
now-a-daze)
- The synthesized code ends up mapping the source code to the above
mentioned latch
- The latch enable signal is sourced from a flip flop.

I doubt that even excruciating timing constraints would get you a reliable
latch because to implement a latch you need, besides timing, a way to
implement redundant logic terms that doesn't get optimized away. You can do
that with non-portable synthesis attributes but there is absolutely no good
reason why you should.

KJ

KJ

"jacko" <> wrote in message
news:197cc6f7-1511-428b-96d5-...
> Hi
>
> I have optimized alu some. and fixed correct return address stacked.
> It is now compiling at 301 LEs, but has a low fmax of 25MHz in C3
> speed MAX II. Is there any way of forcing carry routing via VHDL or is
> that a tool option?
>

What makes you think that 'carry routing' is not being done properly? If
you're only getting 25 MHz you've likely written code that is simply not
following a synchronous design process. Either that or you've got a 100 bit
adder or something else unusual.

Take a look at the critical timing path and try to understand what is really
the bottleneck.

KJ

KJ

"KJ" <> wrote in message
news:bwmnk.32987$...
>
> I'll strongly second Mike's advice and I'd go further and state that
> latches are never safe unless
> - The device actually has a hardware latch as a resource (unlikely
> now-a-daze)
> - The synthesized code ends up mapping the source code to the above
> mentioned latch
> - The latch enable signal is sourced from a flip flop.
>
>
> KJ

Hi Kevin,

All the Xilinx FPGAs I use have latches built in. The storage elements in
the CLBs and the IOBs can be designated either a FF or a latch. Also, I
think your third requirement is awry if by 'latch enable' you mean what I
would call the 'gate'. Normally my latched designs have the gate fed from a
clock.

See Fig.10 of this app note.
http://www.xilinx.com/support/docume...es/xapp233.pdf

Sometimes latches are used because of their superior speed. That said, in
FPGAs, clearly FFs are preferable in almost all circumstances. Including the
case where the designer can't be bothered to code for FFs.

HTH., Syms.

Symon

On Aug 12, 6:07*am, "Symon" <symon_bre...@hotmail.com> wrote:
> "KJ" <kkjenni...@sbcglobal.net> wrote in message
>
> news:bwmnk.32987$...
>
>
>
> > I'll strongly second Mike's advice and I'd go further and state that
> > latches are never safe unless
> > - The device actually has a hardware latch as a resource (unlikely
> > now-a-daze)
> > - The synthesized code ends up mapping the source code to the above
> > mentioned latch
> > - The latch enable signal is sourced from a flip flop.
>
> > KJ
>
> Hi Kevin,
>
> All the Xilinx FPGAs I use have latches built in.

Then that meets the first requirement. Making sure that your code
gets mapped to those elements to meet #2 is still a manual
verification task. As long as one doesn't get too creative in
applying logic to generating the latch enable/gate signal then it
should all work out.

> Also, I
> think your third requirement is awry if by 'latch enable' you mean what I
> would call the 'gate'. Normally my latched designs have the gate fed from a
> clock.
>
Right, I should've said something more along the lines of that the
latch enable/gate signal must have absolutely no glitches, (i.e. like
a clock)...the point being that the output of any logic function
should not be used...amazingly enough, that simple point was the cause
for several failures that I investigated. The other common failure
being when the device didn't have hard latches so they got cobbled
together out of the existing logic but didn't cover the logic hazard
(or race condition if you prefer) either explicitly or because it got
optimized away since it's redundant...all of that was a long while ago
though.

KJ

KJ