Nibz processor @ 472 LEs (16 bit generic specified)

[jacko]

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

 

[Mike Treseler]

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

 

[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

 

[Mike Treseler]

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

 

[jacko]

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]

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

 

[KJ]

On Aug 12, 6:07 am, "Symon" <symon_bre...@hotmail.com> wrote:

"KJ" <kkjenni...@sbcglobal.net> wrote in message

news:bwmnk.32987$co7.7807@nlpi066.nbdc.sbc.com...



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

 

[jacko]

On 12 Aug, 12:50, KJ <kkjenni...@sbcglobal.net> wrote:

On Aug 12, 6:07 am, "Symon" <symon_bre...@hotmail.com> wrote:



"KJ" <kkjenni...@sbcglobal.net> wrote in message

news:bwmnk.32987$co7.7807@nlpi066.nbdc.sbc.com...

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

Ya not the problem now, got rid of all inferred latches, added carry
register bit, now at 33+ MHz. Still one fault to fix, and zero
assignments to do on unused state machine states. Very compact now,
but leaves instruction register in q register on a call instruction,
so must fix this.

I assume Quartus means synchronous registered latches, when it says
latches. Clocked latches would be another way of saying this.

cheers
jacko