FSM in BlockRAM

Fri Mar 05, 2010 12:39 pm   

Hello to all !

I've problem with finite state machine. Because I have not much place in m
FPGA and I need to create few more FSM i found that FSM logic can be packe
in to BRAM. I created simple FSM in VHDL and it shows in raport that i
uses Bram but there is a warning :

WARNING:Xst - Cannot use block RAM resources for signal <FSMROM>. Pleas
check that the RAM contents is read synchronously.

I tried to make the simplest FSM but it dont change anything...

Can someone show me an example of code in VHDL of simple state machine tha
can be packed in to BRAM with any warnings, errors. I just worry that m
design won't work. I have ISE 11.1 and Spartan 3a...

Thanks for any response...

XST log :

Reading design: binary.prj

=========================================================================
* HDL Compilation *
=========================================================================
Compiling vhdl file "C:/FPGA PRAM/Debug/MultiCore/Example.vhd" in Librar
work.
Architecture behv of Entity binary is up to date.

=========================================================================
* Design Hierarchy Analysis *
=========================================================================
Analyzing hierarchy for entity <binary> in library <work> (architectur
<behv>).


=========================================================================
* HDL Analysis *
=========================================================================
Analyzing Entity <binary> in library <work> (Architecture <behv>).
Set property "ENUM_ENCODING = 001 010 011 100 101 110 111" for signa
<CS>.
Set property "ENUM_ENCODING = 001 010 011 100 101 110 111" for signa
<NS>.
Entity <binary> analyzed. Unit <binary> generated.


=========================================================================
* HDL Synthesis *
=========================================================================

Performing bidirectional port resolution...

Synthesizing Unit <binary>.
Related source file is "C:/FPGA PRAM/Debug/MultiCore/Example.vhd".
Found finite state machine <FSM_0> for signal <CS>.

-----------------------------------------------------------------------
| States | 7
|
| Transitions | 16
|
| Inputs | 6
|
| Outputs | 3
|
| Clock | CLOCK (rising_edge)
|
| Power Up State | s1
|
| Encoding | compact
|
| Implementation | BRAM
|

-----------------------------------------------------------------------
Summary:
inferred 1 Finite State Machine(s).
Unit <binary> synthesized.


=========================================================================
HDL Synthesis Report

Found no macro
=========================================================================

=========================================================================
* Advanced HDL Synthesis *
=========================================================================

Implementing FSM <FSM_0> on signal <CS> on BRAM.

Synthesizing (advanced) Unit <CS>.
WARNING:Xst - Cannot use block RAM resources for signal <FSMROM>. Pleas
check that the RAM contents is read synchronously.

-----------------------------------------------------------------------
| ram_type | Block |
|

-----------------------------------------------------------------------
| Port A
|
| aspect ratio | 512-word x 6-bit |
|
| mode | write-first |
|
| clkA | connected to signal <Clk_FSM> | rise
|
| weA | connected to internal node | high
|
| addrA | connected to signal <In0> |
|
| diA | connected to internal node |
|
| doA | connected to signal <Out2> |
|

-----------------------------------------------------------------------
| optimization | area |
|

-----------------------------------------------------------------------
Unit <CS> synthesized (advanced).

=========================================================================
Advanced HDL Synthesis Report

Macro Statistics
# FSMs : 1

=========================================================================

=========================================================================
* Low Level Synthesis *
=========================================================================

Optimizing unit <binary> ...

Mapping all equations...
Building and optimizing final netlist ...
Found area constraint ratio of 100 (+ 5) on block binary, actual ratio is
0.

Final Macro Processing ...

=========================================================================
Final Register Report

Found no macro
=========================================================================

=========================================================================
* Partition Report *
=========================================================================

Partition Implementation Status
-------------------------------

No Partitions were found in this design.

-------------------------------

=========================================================================
* Final Report *
=========================================================================

Clock Information:
------------------
-----------------------------------+------------------------+-------+
Clock Signal | Clock buffer(FF name) | Load |
-----------------------------------+------------------------+-------+
CLOCK | BUFGP | 1 |
-----------------------------------+------------------------+-------+

Asynchronous Control Signals Information:
----------------------------------------
No asynchronous control signals found in this design

Timing Summary:
---------------
Speed Grade: -5

Minimum period: 2.625ns (Maximum Frequency: 380.952MHz)
Minimum input arrival time before clock: 1.342ns
Maximum output required time after clock: 6.860ns
Maximum combinational path delay: No path found

=========================================================================

Process "Synthesis" completed successfully


---------------------------------------
Posted through http://www.FPGARelated.com

Fri Mar 05, 2010 1:41 pm   

On 3/5/2010 11:39 AM, de4 wrote:

XAPP291

Fri Mar 05, 2010 5:14 pm   

On 3/5/2010 4:08 PM, Antti wrote:

But it _IS_ an example of 'code in VHDL of [a] simple state machine that
can be packed in to BRAM'.

Syms.

Fri Mar 05, 2010 6:08 pm   

On Mar 5, 2:41 pm, Symon <symon_bre...@hotmail.com> wrote:

xapp291 does NOT show how from SM VHDL code a implementation using
BRAM is generated by the tools

Antti

Fri Mar 05, 2010 6:56 pm   

On Mar 5, 4:39 am, "de4" <de4_at_n_o_s_p_a_m.poczta.onet.pl> wrote:

Are you using the two-process state machine construct?

If so, DON'T.

-a

Fri Mar 05, 2010 7:13 pm   

On Mar 5, 8:08 am, Antti <antti.luk...@googlemail.com> wrote:

This is a very simple design, easily implemented in BRAM (if speed
permits)
You have 7 states, therefore you need 3 (encoded) outputs
You have 6 incoming condition or jump codes.
You use the BRAM as a synchronous look-up table, using as address the
combination of any jump code with any state code.
That means you need 9 inputs, and the BRAM is thus 512 x 3. ( "512 x
6" in your posting is nonsense)
In hardware you must feed the three output bits back to the address
inputs.

You can use any additional otherwise unused outputs as decoded state
descriptors, but that does not change the basic design.

I suppose you know that the addressing information is automatically
registered before it addresses the BRAM (which is really a BROM with
fixed data content)
Do not use any additional output pipelining, optionally available in
some devices.

Unfortunately I cannot give you any VHDL code, but the basic
understanding should help you.

I have described and promoted this type of design for many years.

Peter Alfke, formerly Xilinx Applications (some of you may remember me)

Fri Mar 05, 2010 9:10 pm   

Peter Alfke <alfke_at_sbcglobal.net> wrote:
(snip)


and also notice that you don't post as often as before.

I was not so long ago thinking of asking:

There is picoblaze (8 bit), and microblaze (32 bit), but no
nanoblaze (16 bit) or milliblaze (64 bit). It might even
be interesting to have a femtoblaze (4 bit) processor.

Maybe not so far off topic, as such processors are, at some level,
complicated state machines.

-- glen

Fri Mar 05, 2010 11:19 pm   

On Mar 5, 11:10 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

Blazes...
"Picoblaze" was started by Ken Chapman (still at Xilinx UK) as a
highly optimized design, an app note that works well with 4-input LUTs
and BRAMs. Xilinx has unfortunately always treated it as an
illiigitimate child. (NIH) It lives due to its efficiency, and due to
Ken's competence, enthusiasm, and perseverance.
"Microblaze" was started by Goran Bilski (originally in Sweden, and
now, after some years in Calif., back again in Sweden.)
It has always been treated as a legitimate Xilinx baby, and Goran has
continuously improved it, and more designers are involved. It grew
from 16 bits to 32 bits. Still a highly optimized design.
I have no idea about plans for 64 bits.

I visit the Xilinx cafeteria once every couple of months to chat with
old friends.
I did repeatedly offer my services as a consultant, even without pay,
but there are no takers.

Peter A.

Sat Mar 06, 2010 10:59 am   

Peter Alfke wrote:

you're outside the company's loop now ?
are you an "outcast" already ?



--
http://ygdes.com / http://yasep.org

Sat Mar 06, 2010 8:36 pm   

On Mar 6, 1:59 am, whygee <y...@yg.yg> wrote:

All of it...
But don't feel sorry for me, I am fine.
Feel sorry for a company that is too hung up to take advantage of an
available resource.
Peter A

Sat Mar 06, 2010 10:55 pm   

On Mar 6, 8:10 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

There is a newish 4 bit core here, that could be
a template ? GC49C50x series
http://www.coreriver.co.kr/product-lines/top_corerivermcu.html

Atom summary:
# CPU
- 4-bit reduced 8051 architecture
- Continuous program addressing, not paged.
- 51 instructions including push, pop and logic inst.
- Instruction cycle : fSYS/6
- Multi-level subroutine nesting with RAM based stack.
# On-chip Memories :
- FLASH : 1024 Bytes (including EEPROM : 128 Bytes )
- RAM : 64 nibbles (including stack)

It could also be timely for someone to target the
new QuadSPI Flash to a FPGA core.
Code memory is always the achilles heel of Soft-CPU.

-jg

Sat Mar 06, 2010 11:06 pm   

On Mar 6, 10:55 pm, -jg <jim.granvi...@gmail.com> wrote:

Jim,

1) the 4-bit "Atom" isnt so new
2) NanoBlaze is registered trademark of Xilinx

hm... one of my softcores has been pushed into useable status
its small core that is optimized to run from one single block ram
and to NOT use distributed ram, so it is very small in all vendors
FPGA's
it does have a compromise, 1 instruction takes 4 clock, but well then
it
has windowed register file and no overhead context switching, i do
consider
it much more interesting then ATOM, at least what goes soft cores for
FPGA

Antti

Sat Mar 06, 2010 11:46 pm   

Antti <antti.lukats_at_googlemail.com> wrote:
(snip)


A quick search of uspto.gov didn't find nanoblaze, but,
following the pattern, the 4 bit processor would be femtoblaze,
which also doesn't seem to be registered.

-- glen

Sun Mar 07, 2010 2:09 am   

On Mar 7, 10:06 am, Antti <antti.luk...@googlemail.com> wrote:

It is, relative to an 80C51 ;)


Yes, a core that targets BlockRam is going to be a better fit.
Windowed register is too often overlooked.

Single cycle opcodes are over-rated, and I like the XMOS approach,
where they time-slice to give the illusion of 4 x 100MHz cores.

In a serial Flash CPU, to avoid thrashing the serial memory, and give
superfast interrupts, you would
allocate a small, fast interrupt/FSM type area, and then have one
thread allowed to access serial flash.
Serial flash also naturally has a clocks/opcode number.

One chip will feed 16b/4 clocks, 24b in 6 clocks, and
a Pair, would give 32b in 4 clocks, 40b in 5 clocks.

-jg