Reply by Mike Treseler November 24, 20032003-11-24
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
Reply by Hal Murray November 22, 20032003-11-22
>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.
Reply by Mike Treseler November 22, 20032003-11-22

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
Reply by Hal Murray November 21, 20032003-11-21
>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.
Reply by Goran Bilski November 21, 20032003-11-21
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 > > > >
Reply by Jim Granville November 20, 20032003-11-20
> > 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
Reply by Goran Bilski November 20, 20032003-11-20
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&#4294967295;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 >
Reply by Mike Treseler November 20, 20032003-11-20
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
Reply by Nial Stewart November 20, 20032003-11-20
MM <mbmsv@yahoo.com> wrote in message
news:bpg3er$1neeon$1@ID-204311.news.uni-berlin.de...
> > The bigger downside here is that since the state machines took longer > > than I expected ( I scheduled 3 weeks of design, project took 6 weeks > > ) my manager has warned me to find another job ( fat chance ) as he > > has handed in a review requesting a 20% pay cut ... but my real > > question is about the tools so I may do better next time > > I think you do need to find another job with a better manager! An error in > scheduling made by an engineer doesn't deserve a pay cut. If anyone
deserves
> a pay cut, it's a manager who didn't know a basic management rule: take an > engineer's estimate, multiply it by 2 and then use the next available unit > :) If he knew the rule he would celebrate the work finished way faster
than
> expected!
Especially bearing this in mind... "it worked , after handing over the design to the test department they loaded a board and signed off on the design within a week. My fellow engineers were rather impressed since they knew how complex the control was" This would seem to demonstrate that careful up front design saved time in test and verification. I'd point that out to your 'manager' and his boss before telling him where to shove his job (after you've found something better). Nial ------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design www.nialstewartdevelopments.co.uk
Reply by Marc Randolph November 20, 20032003-11-20
Hal Murray wrote:
[...]
> Your idea would probably get used a lot more if there was > an example all worked out. In particular, you need an assembler > so that other people can use it as a skeleton. And as others > have mentioned, you need an example that shows how the microcode > gets through the tool chain and merged into the FPGA bit stream. > > What's a good toy example? Can we think of something semi-useful > (toy) that would run on a demo board? It would need 50-100 states. > I might be willing to hack together some software if somebody would > do the rest of the work.
How about something better than just a toy, but nearly as easy to describe? Something that could be donated to opencores and would actually be reused would surely be more worth someones time (while still useful to students and/or others wanting to see a real world example of this). I'd be interesting in helping on a project like that. Here is my idea that takes up a non-trivial amount of space in an FPGA: Ethernet (especially GbE) has the ability to send PAUSE frames (I'll just call them packets since that is what many call them). While a device is receiving one of these packets, it must verify that it is valid (say 16 bits at a time, for 64 bytes, including CRC). Once verified, it outputs a hold signal for the amount of time specified in the PAUSE packet. The hold signal can be used to stop transmitting data in the opposite direction. This is a simple state machine and could easily be put into BRAM(s), using the BRAM to compare and validate each 16 bit word. There are actually two different packets that are valid to receive (they differ only in the first six bytes), hence there there are two valid states for the first couple words, after which they will recombine to a single valid state thereafter. Now imagine this for a multi-port system. 24 ports aren't uncommon on systems anymore, and you'd need a state machine for each port (or one larger [and much faster] one that does context switches) to verify the reception of the packets (possibly simultaneously). You also need a "multi-port" timer that signals when it is ok to start transmitting data again. Having 24 stand-alone timers seems like quite a waste (although they can be quite slow since the unit of measure of the "pause time" field is 409.6 ns at GbE rates).
> Has anybody considered using LUT sized ROMs for state machines? > It doesn't seem likely to be practical but might make an interesing > exercise. The classic traffic light controller or vending machine > might fit.
I'm not sure why it wouldn't be practical, except that the amount of resources saved (a couple LUTS) may not be worth the effort involved (unless there was a program that just spit out the LUT contents for you, as you have been discussing). Marc