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