State Machines....

I agree.

This "block ram as state machine" needs a synthesis module generator so that it can be inferred from code.

Otherwise, I have to leave the comfortable confines of a VHDL clocked process and I have two types of source code to maintain.

-- Mike Treseler

Reply to
Mike Treseler
Loading thread data ...

Hi,

The latest version of XST in ISE 6.1 have an option to synthesize a state machine using BRAM as a resource instead of LUTs. It's called FSM_STYLE

Göran

Mike Treseler wrote:

Reply to
Goran Bilski

You mean FSM_STYLE lets you choose between (guessing here) One-Hot, Binary, Gray Code, (whatever), or BRAM based ?

Another solution to (complex) state engines appeared in the CR2 web seminar, for which Xilinx use the bland term (IIRC) 'Program Memory Integration' in the PicoBlaze.

What this _actually_ does is rather more complex, and powerful.

The Assembler creates a VHD file for simulation, which is run with the PicoBlaze core, to verify the design. Std soft core operation so far.... Turns out you can recompile both files, as you NOW have a VHD description of the whole system (Core + ASM.VHD) description, and the tools can optimise away redundant logic, and create a smaller/faster logic solution, that started life looking like a 'Tiny_uC and SW in small ROM', but is now whatever the tools optimise to. Not just a soft uC, but a squishy one :)

-jg

Reply to
Jim Granville

No, That is another parameter.

If you look under properties in ProjNav for XST. Under the HDL options you will find "FSM Encoding Algorithm" where you can set to Auto,One-Hot,Compact,Sequential,Gray,Johnson,User,None Two lines below you have the option "FSL Style" which you can set to LUT or bram

This is for ISE 6. and when advanced is selected which is selected uner Edit -> Preferences under the tab Processes

Göran

Jim Granville wrote:

Reply to
Goran Bilski

But one of the reasons for putting a big state machine in a ROM is so that you can treat it as a software problem.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

I would prefer to write the "software" in vhdl, and have synthesis fit it to the block rom when appropriate.

-- Mike

Reply to
Mike Treseler

How big does a state machine have to get before you want to think of it as software?

How about 100 lines of PIC/AVR code? That's pretty simple as software goes.

How many lines of VHDL/Verilog does it take per state?

Would you be happy with a reverse assembler? That is a program that would translate the (special) assmebler language into your VHDL?

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

A synchronous VHDL process is already a virtual machine that runs a complete loop every clock tick. I already can shift, add, move to a variable, move to or from a variable of any type I like. I am not even limited to a single operation per tick.

My point is that rather than making a new, more-limited language to suck up unused block rams, let's add smarts to synthesis so that it knows how to make a block of logic *for any purpose* out of a rom when other resources get tight.

-- Mike Treseler

Reply to
Mike Treseler

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.