State Machines....

Jim Granville wrote:

> It is a good idea, but the SW tool side could need work to help it take
> off.. :)

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

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:

> Jim Granville wrote:
>
>> It is a good idea, but the SW tool side could need work to help it take
>> off.. :)
>
>
> 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
>

> > Jim Granville wrote:
> >
> >> It is a good idea, but the SW tool side could need work to help it take
> >> off.. :)
> >
"Goran Bilski" <goran@xilinx.com> wrote in message
news:3FBD0BBD.9000306@xilinx.com...
> 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

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

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:

>>>Jim Granville wrote:
>>>
>>>      
>>>
>>>>It is a good idea, but the SW tool side could need work to help it take
>>>>off.. :)
>>>>        
>>>>
>"Goran Bilski" <goran@xilinx.com> wrote in message
>news:3FBD0BBD.9000306@xilinx.com...
>  
>
>>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
>>    
>>
>
>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
>
>
>  
>

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

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.

Hal Murray wrote:

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

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

            -- Mike

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

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.

Hal Murray wrote:

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

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