Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Dec 6, 5:09=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > On 5 Dez., 04:55, rickman <gnu...@gmail.com> wrote: > > > > > On Dec 4, 8:05=A0pm, Jonathan Ross <TheProperN...@psychophile.com> > > wrote: > > > > On Dec 4, 5:32=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > I suppose this is something that you need to expect, but I just hav= e > > > > never come across this before. =A0I have some concurrent logic equa= tions > > > > using integers where one input common to two assignments changes an= d > > > > because one gets updated before the other, one is set to a value th= at > > > > is outside the range of the integer and flags an error in > > > > simulation. > > > > > C <=3D B - A * stuff; > > > > D <=3D A + C; =A0-- A changes and puts D outside of its range until= C is > > > > updated > > > > > In the real world, this is not really an issue since all sorts of > > > > intermediate states are expected when doing arithmetic. =A0But VHDL > > > > doesn't seem to accommodate this well. =A0The only way I can think = of to > > > > fix this, without changing the logic, is to do these calculations > > > > inside a combinatorial process using variables. =A0Then I can contr= ol > > > > the sequence of updates explicitly. > > > > > The only other thing I can think is to assign A to A' and use A' in > > > > place of A in the assignment for D. =A0That may still allow an erro= r, > > > > but if A'' is used, then there will be two delta delays in D > > > > assignment path. =A0However, if C grows because A has shrunk, then = that > > > > could cause the same sort of out of bounds error on D. > > > > > Is there another way make this work that isn't so cumbersome? > > > > > Rick > > > > Try using either the SIGNED or UNSIGNED type instead of integer. > > > I see what the two of you are saying. =A0By using integer it will be > > tested for range bounds. =A0std_logic_vector types don't get that level > > of analysis. =A0The range testing is useful when it is done properly. > > By properly, I mean so that it is checking the logic, not your skill > > at eliminating glitches in combinatorial logic... > > Use signed or unsigned from the numeric_std package and perform the > range check yourself > at times when you know the intermediate states have settled: > > if rising_edge(clk) then > =A0 assert c >=3D lower_bound and c <=3D upper_bound report "C out of > range"; > end if; > > I believe that virtually all HDL-Designers should use a lot more > assertions than they do. > (Myself included.) > > Kolja That's an interesting approach. I'm not accustomed to using assertions in my synthesizable code, but there is certainly no reason not to. RickArticle: 150001
On Dec 6, 8:15=A0am, Anders.Monto...@kapsi.spam.stop.fi.invalid wrote: > stephen.cra...@gmail.com <stephen.cra...@gmail.com> wrote: > > Is the Smockie lab coat mentioned for real, or is it Vaporwear? > > Badum-tish. The product page mentioned in the video exists, but is a joke > (<http://www.latticesemi.com/products/cpld/machxo2/smockie.cfm>), but if > they don't have them to give out at trade shows they're fools. > > -a I don't normally go to trade shows, but I would go to get one of those! RickArticle: 150002
On Dec 6, 5:20=A0am, "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > >>Anyway...probably I was wrong...I don't need to avoid registered output > >>(and a lot of you were right)...in fact I'm always assigning the > "output" > >>of a FF...therefore I'm sure that when fsm reach a state the output wil= l > >>change to the value that is required on that state on the same clock > >front > >>and I don't have to wait for another clock front to have that value on > >>output... > >This is not completely true...state change immediately if change > condition > >is met...output is still at values on previous state...on the next clock > >front the output goes to the new state value...this is the effect of the > >output FF...I'm sorry a misunderstanding.... > > >..the difference is now clear....I've just simulated the two > >situations...(1 process, 2 process-no register)...and checked the > >differences.... > > >Anyway...since all input signals "should be sinchronous" to the raise > front > >of the clock and the produced output MUST be synch I think that the best > >way to achieve that is registering output and evaluating input on clock > >raise...my previous implementation was wrong because output is allowed t= o > >change asynchronously...I have to correct...and I think that 1 process > >style fit better the requirements... > > >If in some cases I will need to unreg output I will use concurrent > >statements outside of the process as pointed out in the discussion... > > >Thanx to everyone who helped me... > >Carlo =A0 > > Something that no-one seems to have brought up (sorry if I missed it) is > whether you are trying to implement a Mealy FSM or a Moore FSM. What you > are doing will infer a Mealy FSM, but I suspect that you don't know why y= ou > are using that version. Reading up on the difference should be helpful - > there is a lot of stuff available on the Interwebs that any decent search > engine will find. > > For high-speed stuff, I usually go for a Moore FSM, but with registered > outputs via a slightly subtle variation. That's why I never bother to use these definitions anymore. I never code either machine type really. I design FSMs to suit my situation. These two machine types were created to facilitate the mathematical analysis of FSMs and I find using these terms adds little to analyzing my design. Just my two cents... RickArticle: 150003
On Dec 6, 6:02=A0am, "carlob" <carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it> wrote: > >Something that no-one seems to have brought up (sorry if I missed it) is > >whether you are trying to implement a Mealy FSM or a Moore FSM. What you > >are doing will infer a Mealy FSM, but I suspect that you don't know why > you > >are using that version. Reading up on the difference should be helpful - > >there is a lot of stuff available on the Interwebs that any decent searc= h > >engine will find. > > >For high-speed stuff, I usually go for a Moore FSM, but with registered > >outputs via a slightly subtle variation. > > >--------------------------------------- =A0 =A0 =A0 =A0 =A0 =A0 > >Posted throughhttp://www.FPGARelated.com > > Hi, > Yes...it was a Mealy FSM...the output depends on state and > input...otherwise you can add more states and move to Moore...but...when > you register the output are you already going toward Moore or not??? I > think that are similar... > > It could be interesting to have more info on the the high-speed stuff... The Mealy vs Moore doesn't have to do with registering the outputs. That is just an issue of delays since registering the inputs and/or the outputs delays the outputs. The real difference is that the outputs become a sort of separate state machine on their own although the output values don't feed back to affect either the machine state or the output state. But the outputs are an independent function of the inputs and the outputs. The outputs can change value with input changes without the state changing. The outputs can have a different value for the same state depending on how you reached that state. I used to design FSMs considering the issues of Mealy vs Moore, but now I just design FSMs based on what I need and don't even bother with the M v. M distinction. The bottom line is there are many variations on the theme, so why bother with just these two? RickArticle: 150004
On Dec 6, 8:57=A0am, rickman <gnu...@gmail.com> wrote: > On Dec 6, 5:09=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > > > > > > > On 5 Dez., 04:55, rickman <gnu...@gmail.com> wrote: > > > > On Dec 4, 8:05=A0pm, Jonathan Ross <TheProperN...@psychophile.com> > > > wrote: > > > > > On Dec 4, 5:32=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > > I suppose this is something that you need to expect, but I just h= ave > > > > > never come across this before. =A0I have some concurrent logic eq= uations > > > > > using integers where one input common to two assignments changes = and > > > > > because one gets updated before the other, one is set to a value = that > > > > > is outside the range of the integer and flags an error in > > > > > simulation. > > > > > > C <=3D B - A * stuff; > > > > > D <=3D A + C; =A0-- A changes and puts D outside of its range unt= il C is > > > > > updated > > > > > > In the real world, this is not really an issue since all sorts of > > > > > intermediate states are expected when doing arithmetic. =A0But VH= DL > > > > > doesn't seem to accommodate this well. =A0The only way I can thin= k of to > > > > > fix this, without changing the logic, is to do these calculations > > > > > inside a combinatorial process using variables. =A0Then I can con= trol > > > > > the sequence of updates explicitly. > > > > > > The only other thing I can think is to assign A to A' and use A' = in > > > > > place of A in the assignment for D. =A0That may still allow an er= ror, > > > > > but if A'' is used, then there will be two delta delays in D > > > > > assignment path. =A0However, if C grows because A has shrunk, the= n that > > > > > could cause the same sort of out of bounds error on D. > > > > > > Is there another way make this work that isn't so cumbersome? > > > > > > Rick > > > > > Try using either the SIGNED or UNSIGNED type instead of integer. > > > > I see what the two of you are saying. =A0By using integer it will be > > > tested for range bounds. =A0std_logic_vector types don't get that lev= el > > > of analysis. =A0The range testing is useful when it is done properly. > > > By properly, I mean so that it is checking the logic, not your skill > > > at eliminating glitches in combinatorial logic... > > > Use signed or unsigned from the numeric_std package and perform the > > range check yourself > > at times when you know the intermediate states have settled: > > > if rising_edge(clk) then > > =A0 assert c >=3D lower_bound and c <=3D upper_bound report "C out of > > range"; > > end if; > > > I believe that virtually all HDL-Designers should use a lot more > > assertions than they do. > > (Myself included.) > > > Kolja > > That's an interesting approach. =A0I'm not accustomed to using > assertions in my synthesizable code, but there is certainly no reason > not to. > > Rick- Hide quoted text - > > - Show Iquoted text - I have not tried it, but what is below may do what you want also. signal G_sv : signed(10 downto 0); signal Signed_int : integer range -128 to 127; -- specified valid range here ................. if rising_edge(clk) then Signed_int <=3D TO_INTEGER(G_sv); end if;Article: 150005
On Dec 6, 9:30=A0am, Newman <newman5...@yahoo.com> wrote: > On Dec 6, 8:57=A0am, rickman <gnu...@gmail.com> wrote: > > > > > > > On Dec 6, 5:09=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > > > > On 5 Dez., 04:55, rickman <gnu...@gmail.com> wrote: > > > > > On Dec 4, 8:05=A0pm, Jonathan Ross <TheProperN...@psychophile.com> > > > > wrote: > > > > > > On Dec 4, 5:32=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > > > I suppose this is something that you need to expect, but I just= have > > > > > > never come across this before. =A0I have some concurrent logic = equations > > > > > > using integers where one input common to two assignments change= s and > > > > > > because one gets updated before the other, one is set to a valu= e that > > > > > > is outside the range of the integer and flags an error in > > > > > > simulation. > > > > > > > C <=3D B - A * stuff; > > > > > > D <=3D A + C; =A0-- A changes and puts D outside of its range u= ntil C is > > > > > > updated > > > > > > > In the real world, this is not really an issue since all sorts = of > > > > > > intermediate states are expected when doing arithmetic. =A0But = VHDL > > > > > > doesn't seem to accommodate this well. =A0The only way I can th= ink of to > > > > > > fix this, without changing the logic, is to do these calculatio= ns > > > > > > inside a combinatorial process using variables. =A0Then I can c= ontrol > > > > > > the sequence of updates explicitly. > > > > > > > The only other thing I can think is to assign A to A' and use A= ' in > > > > > > place of A in the assignment for D. =A0That may still allow an = error, > > > > > > but if A'' is used, then there will be two delta delays in D > > > > > > assignment path. =A0However, if C grows because A has shrunk, t= hen that > > > > > > could cause the same sort of out of bounds error on D. > > > > > > > Is there another way make this work that isn't so cumbersome? > > > > > > > Rick > > > > > > Try using either the SIGNED or UNSIGNED type instead of integer. > > > > > I see what the two of you are saying. =A0By using integer it will b= e > > > > tested for range bounds. =A0std_logic_vector types don't get that l= evel > > > > of analysis. =A0The range testing is useful when it is done properl= y. > > > > By properly, I mean so that it is checking the logic, not your skil= l > > > > at eliminating glitches in combinatorial logic... > > > > Use signed or unsigned from the numeric_std package and perform the > > > range check yourself > > > at times when you know the intermediate states have settled: > > > > if rising_edge(clk) then > > > =A0 assert c >=3D lower_bound and c <=3D upper_bound report "C out of > > > range"; > > > end if; > > > > I believe that virtually all HDL-Designers should use a lot more > > > assertions than they do. > > > (Myself included.) > > > > Kolja > > > That's an interesting approach. =A0I'm not accustomed to using > > assertions in my synthesizable code, but there is certainly no reason > > not to. > > > Rick- Hide quoted text - > > > - Show Iquoted text - > > I have not tried it, but what is below may do what you want also. > > signal G_sv =A0 =A0 =A0 =A0 =A0 =A0 : signed(10 downto 0); > signal Signed_int =A0 : integer range -128 to 127; =A0 -- specified valid > range here > ................. > > if rising_edge(clk) then > =A0 Signed_int <=3D =A0 TO_INTEGER(G_sv); > end if;- Hide quoted text - > > - Show quoted text - I might have wrongly assumed that the combinatorial result was going to be eventually registered. Oops!Article: 150006
>On Dec 6, 6:02=A0am, "carlob" ><carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it> wrote: >> >Something that no-one seems to have brought up (sorry if I missed it) is >> >whether you are trying to implement a Mealy FSM or a Moore FSM. What you >> >are doing will infer a Mealy FSM, but I suspect that you don't know why >> you >> >are using that version. Reading up on the difference should be helpful - >> >there is a lot of stuff available on the Interwebs that any decent searc= >h >> >engine will find. >> >> >For high-speed stuff, I usually go for a Moore FSM, but with registered >> >outputs via a slightly subtle variation. >> >> >--------------------------------------- =A0 =A0 =A0 =A0 =A0 =A0 >> >Posted throughhttp://www.FPGARelated.com >> >> Hi, >> Yes...it was a Mealy FSM...the output depends on state and >> input...otherwise you can add more states and move to Moore...but...when >> you register the output are you already going toward Moore or not??? I >> think that are similar... >> >> It could be interesting to have more info on the the high-speed stuff... > >The Mealy vs Moore doesn't have to do with registering the outputs. >That is just an issue of delays since registering the inputs and/or >the outputs delays the outputs. The real difference is that the >outputs become a sort of separate state machine on their own although >the output values don't feed back to affect either the machine state >or the output state. But the outputs are an independent function of >the inputs and the outputs. The outputs can change value with input >changes without the state changing. The outputs can have a different >value for the same state depending on how you reached that state. > Strictly speaking you are right... :-)) >I used to design FSMs considering the issues of Mealy vs Moore, but >now I just design FSMs based on what I need and don't even bother with >the M v. M distinction. The bottom line is there are many variations >on the theme, so why bother with just these two? > >Rick > Yes...in effect...you are right....I usually don't pay attention to Moore/Mealy too.... Carlo --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150007
I am looking to get started with Linux on a Microblaze. There seems to be a few companies out there doing it and Xilinx has a Wiki site. What exactly is the difference between the Xilinx and the others. Presumably you have to pay for the others, although I thought Linux was supposed to be free. So I would of thought I should be able to get hold of the source even if I dont get any support. Any thoughts would be helpful Thanks Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150008
Digilent offers low-cost FPGA boards with VHDL or Verilog textbook written for that board. http://www.digilentinc.com/Products/Detail.cfm?NavPath=3D2,400,790&Prod= =3DBASYS2 http://www.digilentinc.com/Products/Detail.cfm?NavPath=3D2,400,789&Prod= =3DNEXYS2 Bryan On Dec 3, 6:01=A0am, RealInfo <therighti...@gmail.com> wrote: > Hi all > I need to buy a FPGA evaluation board to practice my comeback > to the FPGA design with VHDL. > > Can you offer me a board that will do that > =A0based on your experience ? > > Thanks > > ECArticle: 150009
On Dec 6, 7:00=A0am, "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > I am looking to get started with Linux on a Microblaze. There seems to be= a > few companies out there doing it and Xilinx has a Wiki site. What exactly > is the difference between the Xilinx and the others. Presumably you have = to > pay for the others, although I thought Linux was supposed to be free. So = I > would of thought I should be able to get hold of the source even if I don= t > get any support. > > Any thoughts would be helpful > > Thanks > > Jon > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com You're not paying for The Kernel, you're paying for the effort of porting it. Most (all?) GPL flavors allow compensation for effort. What I remember from the last time I tried the Xilinx app notes is that the Xilinx version was both PPC and NLA. There are sources out there for free, and perhaps a bootable image or two. Most of what I have seen are uClinux variants; every one I found stopped being updated after the creator graduated from school. :) And don't be too surprised if what's out there is completely incompatible with your hardware (the joys of a soft processor). RKArticle: 150010
On Dec 6, 3:13=A0am, Mike Harrison <m...@whitewing.co.uk> wrote: > http://www.youtube.com/watch?v=3Dh_USk-HNgPA&feature=3Dplayer_detailpage > > Come on X and A - spice up your promo =A0videos! Everybody chooses what is important to them. Some like snazzy videos, some like to ship product to customers...Article: 150011
On Dec 4, 12:20=A0pm, Gabor <ga...@alacron.com> wrote: > > By the way, I know it's not as much fun as seeing a design come alive > in hardware, but you can get started with VHDL with no more than > a free software download from any major FPGA vendor and use > the castrated version of simulator that comes with it. > > -- Gabor The Ashenden book (which IMnsHO is an excellent VHDL reference) has a not-brain-dead simulator included. RKArticle: 150012
On 12/06/2010 09:01 AM, d_s_klein wrote: > On Dec 6, 7:00 am, "maxascent" > <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: >> I am looking to get started with Linux on a Microblaze. There seems to be a >> few companies out there doing it and Xilinx has a Wiki site. What exactly >> is the difference between the Xilinx and the others. Presumably you have to >> pay for the others, although I thought Linux was supposed to be free. So I >> would of thought I should be able to get hold of the source even if I dont >> get any support. >> >> Any thoughts would be helpful >> >> Thanks >> >> Jon >> >> --------------------------------------- >> Posted throughhttp://www.FPGARelated.com > > You're not paying for The Kernel, you're paying for the effort of > porting it. Most (all?) GPL flavors allow compensation for effort. Could you please cite chapter and verse? That's 180 degrees out from what I read the last time I went over a GPL in its entirety. Per the GPL, if you distribute the software in any way shape or form it has to be free, and you have to distribute source code. The way people make money on this stuff is by never documenting it well, and offering consulting and/or training services. Or if it's a more widely available product (like a desktop OS) they'll document it well enough that an individual will like it, then offer consulting for the corporate user. Bottom line: the software has to be free, but it doesn't have to be easy. The marketplace has evolved various means to allow individuals and companies to make money off the "doesn't have to be easy" part. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 150013
Hi, I could not get windrv to work, as running Debian, and it seems very picky about the version/distro it will work with, so have gone down the route of trying to get the open source drivers working. Does any body have any experience of getting the libusb-driver to work? I'm following the instructions here: http://git.zerfleddert.de/cgi-bin/gitweb.cgi/usb-driver?a=blob_plain;f=README;hb=HEAD All good down to the point where I launch iMPACT and test the cable. 'lsusb' outputs: Bus 002 Device 009: ID 03fd:0008 Xilinx, Inc. The '0008' indicating that the Xilinx firmware has succesfully loaded. Unfortunately, iMPACT outputs: PROGRESS_START - Starting Operation. Reusing A0012001 key. Reusing 24012001 key. Using windrvr6 driver. Connecting to cable (Usb Port - USB21). Checking cable driver. File version of /opt/Xilinx/12.2/ISE_DS/ISE/bin/lin64/xusbdfwu.hex = 1030. File version of /etc/hotplug/usb/xusbdfwu.fw/xusbdfwu.hex = 1030. libusb-driver.so version: 2010-05-26 09:11:43. Cable PID = 0008. Max current requested during enumeration is 74 mA. write cmdbuffer failed FFFFFFFFFFFFFFFF. write cmdbuffer failed FFFFFFFFFFFFFFFF. Loopback test failed. Sent character = 00, Received character = 00. PROGRESS_END - End Operation. I'm not sure if its even trying to talk to the right usb device. The cable is clearly on Bus 002 Device 009, and iMPACT is trying Usb Port USB21. I'm not sure what the mapping between busses, devices and ports is all about... anyone? Thanks for any help you can give me. RupertArticle: 150014
I think I would use a function for the intermediate calculation, and then call the function in both concurrent assignment statements per the original implementation. Integers give you the benefits of bounds checking in simulation (even below the 2^n granularity if desired), and a big improvement in simulation performance, especially if integers are widely used in the design (instead of vectors). AndyArticle: 150015
Thank you Jonathan, Pontus and Alessandro for your comments and suggestions -- I will consider them for the next revision of the document. On Dec 6, 1:18=A0am, Alessandro Basili <alessandro.bas...@cern.ch> wrote: > In the end I believe that having a structure, regardless the type, is > the most important thing, since nothing can be more confusing than > having no organization. That's the main point, yes. The primary motivation for writing this specification was to provide a starting point for engineers, together with the reasoning behind the choices that I have made. Obviously, there's no way for a single structure definition to fit everyone's needs. I do think, though, that within the rigid rules of this proposal, there's enough flexibility for customization without loss of most benefits. Further comments and suggestions are welcome! cheers, saar.Article: 150016
On Dec 6, 1:00=A0pm, Andy <jonesa...@comcast.net> wrote: > I think I would use a function for the intermediate calculation, and > then call the function in both concurrent assignment statements per > the original implementation. > > Integers give you the benefits of bounds checking in simulation (even > below the 2^n granularity if desired), and a big improvement in > simulation performance, especially if integers are widely used in the > design (instead of vectors). > > Andy I know everyone says that integers run faster, but is this a significant effect? Has it been measured or at least verified on current simulators? RickArticle: 150017
Hi, I have a design in which I use multiple cores for connecting to different interfaces: SPI, I2C, UART, etc. Each interface outputs the data to memory. I want to be able to both transmit data from the interface cores, read data from them and configure them (baud rate for example for UART). How can I do this? Can I use the Wishbone bus and build a master core to drive the operations, the interface cores being the slaves? Is it much easier if don't use the Wishbone and just build my own interconnections bus? Basically my question is how do large design connect cores, do they all use a microprocessor? Looks like it by what I see on Xilinx' website, for example. Thanks --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150018
>Hi, > >I have a design in which I use multiple cores for connecting to different >interfaces: SPI, I2C, UART, etc. Each interface outputs the data to memory. >I want to be able to both transmit data from the interface cores, read data >from them and configure them (baud rate for example for UART). How can I do >this? Can I use the Wishbone bus and build a master core to drive the >operations, the interface cores being the slaves? Is it much easier if >don't use the Wishbone and just build my own interconnections bus? >Basically my question is how do large design connect cores, do they all use >a microprocessor? Looks like it by what I see on Xilinx' website, for >example. > >Thanks What you need is a bus to connect your modules to memory. Usually the devices you mention would be slaves on the bus and you would have a processor as a master to read the data and send it to memory. There are a number of standard buses like PLB from IBM and AMBA from ARM. Xilinx have used PLB in the past but are now using buses from ARM. I havent used Wishbone but I dont see why you could not. You could design your own simple bus using some mux and control signals. It all depends how complex you need it. Regards Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150019
On 6 d=E9c, 13:25, saar drimer <saardri...@gmail.com> wrote: > Thank you Jonathan, Pontus and Alessandro for your comments and > suggestions -- I will consider them for the next revision of the > document. > > On Dec 6, 1:18=A0am, Alessandro Basili <alessandro.bas...@cern.ch> > wrote: > > > In the end I believe that having a structure, regardless the type, is > > the most important thing, since nothing can be more confusing than > > having no organization. > > That's the main point, yes. The primary motivation for writing this > specification was to provide a starting point for engineers, together > with the reasoning behind the choices that I have made. Obviously, > there's no way for a single structure definition to fit everyone's > needs. I do think, though, that within the rigid rules of this > proposal, there's enough flexibility for customization without loss of > most benefits. > > Further comments and suggestions are welcome! > > cheers, > saar. I was just wondering, with your project structure, where would vendor- specific cores would fit in? Let's say I use core generator to generate a FIR filter. Coregen generates a .xco file along with .ngc, .mif .vhd (for simulation), etc. Where would you put it in your structure and what files would you add to your version control. Technically, you only need the .xco file, and maybe the .coef file the regenerate your core. However, if you have a lot of cores, it might take a lot of time to regenerate the missing core files.Article: 150020
rickman <gnuarm@gmail.com> wrote: (snip) > The Mealy vs Moore doesn't have to do with registering the outputs. > That is just an issue of delays since registering the inputs and/or > the outputs delays the outputs. The real difference is that the > outputs become a sort of separate state machine on their own although > the output values don't feed back to affect either the machine state > or the output state. But the outputs are an independent function of > the inputs and the outputs. The outputs can change value with input > changes without the state changing. The outputs can have a different > value for the same state depending on how you reached that state. > I used to design FSMs considering the issues of Mealy vs Moore, but > now I just design FSMs based on what I need and don't even bother with > the M v. M distinction. The bottom line is there are many variations > on the theme, so why bother with just these two? Many years ago, I was using some system with a state machine compiler. After doing a design (I believe as part of a tutorial session) I figured out that my design was somewhere between Mealy and Moore. Also, I once found a bug in the Altera state machine optimizer, by designing one in a way that the tools didn't expect. It seems that the tools wanted a separate verilog case block for state selection and output generation. I believe that is independent of the Mealy vs. Moore question, but they are much easier for me to read with state selection and output selection together. -- glenArticle: 150021
Thanks for the response. I know I can use Wishbone for interconnecting some slave devices to a microprocessor but the idea is that I want to get away without using a microprocessor. So the question is can another device, other than microprocessor, be master on a Wishbone bus? Or on any other bus... How can I get away without using a microprocessor? From your experience designing a FSM is much more time consuming than using a simple microprocessor core (in this case I have to spend time 1) learning to program it and 2) writing the code)? >>Hi, >> >>I have a design in which I use multiple cores for connecting to different >>interfaces: SPI, I2C, UART, etc. Each interface outputs the data to >memory. >>I want to be able to both transmit data from the interface cores, read >data >>from them and configure them (baud rate for example for UART). How can I >do >>this? Can I use the Wishbone bus and build a master core to drive the >>operations, the interface cores being the slaves? Is it much easier if >>don't use the Wishbone and just build my own interconnections bus? >>Basically my question is how do large design connect cores, do they all >use >>a microprocessor? Looks like it by what I see on Xilinx' website, for >>example. >> >>Thanks > >What you need is a bus to connect your modules to memory. Usually the >devices you mention would be slaves on the bus and you would have a >processor as a master to read the data and send it to memory. There are a >number of standard buses like PLB from IBM and AMBA from ARM. Xilinx have >used PLB in the past but are now using buses from ARM. I havent used >Wishbone but I dont see why you could not. You could design your own simple >bus using some mux and control signals. It all depends how complex you need >it. > >Regards > >Jon > >--------------------------------------- >Posted through http://www.FPGARelated.com > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150022
On Dec 6, 9:18=A0am, Tim Wescott <t...@seemywebsite.com> wrote: > > Could you please cite chapter and verse? > -- > > Tim Wescott > Wescott Design Serviceshttp://www.wescottdesign.com > According to gnu.org: "Many people believe that the spirit of the GNU Project is that you should not charge money for distributing copies of software, or that you should charge as little as possible =97 just enough to cover the cost. This is a misunderstanding." <http://www.gnu.org/philosophy/selling.html>Article: 150023
> I was just wondering, with your project structure, where would vendor- > specific cores would fit in? Let's say I use core generator to > generate a FIR filter. Coregen generates a .xco file along > with .ngc, .mif .vhd (for simulation), etc. Where would you put it in > your structure and what files would you add to your version control. > Technically, you only need the .xco file, and maybe the .coef file the > regenerate your core. However, if you have a lot of cores, it might > take a lot of time to regenerate the missing core files. Some of this is already covered in the document; see the "build environment" section. This is the Makefile bit (I've noted that I'm inconsistent with "/source" and "/sources", and will fix it in the next revision): CGP = fifo # Generate black boxes # (Unfortunately, CoreGen will generate the core where the .cgp and # .xco files are, NOT from where it is invoked. There is no output # path directive either. Hack is to copy the source files first) %.v %.cgp: cp ../sources/blackbox/$(CGP).cgp $(SYN)/$(CGP).cgp cp ../sources/blackbox/$(CGP).xco $(SYN)/$(CGP).xco cd $(SYN) && coregen -p $(CGP).cgp -b $(CGP).xco bbox: $(SYN)/$(CGP).v $(SYN)/$(CGP).cgp I'm suggesting that the required source files (in this case, .xco and .cgp) be put in version control at "/sources/blackbox" (for a single core). An FIR filter and FIFO source files could sit in "/ sources/blackbox/fir_filter", and "/sources/blackbox/fifo", respectively. "blackbox" isn't special -- they could similarly be placed in "/sources/fir_filter", and "/sources/fifo", and the Makefile changed accordingly. Another valid option is to consider these cores as submodules with a build of their own, though I decided not to do that because these modules typically aren't significant enough to justify it. Generated files (.vhd/.v, .ngc, etc.) are placed in "/build/synthesis/ <core name>/", for example. The Makefile should know when to regenerate the required files if they are missing. Indeed, generating the .ngc files take a long time, so "/build/synthesis/<core name>/" shouldn't be deleted too often... this can also be set up by the Makefile (i.e., selective clean of the various generated directories, as I have it in the example Makefile in the document for "syn" and "imp"). cheers, saar.Article: 150024
I really do not recommend combined clocked processes with
combinatorial paths from in to out. They tend to have many of the
disadvantages of both clocked and combinatorial processes.
What's the difference between adding a flag (v_delay) and adding
another state?
In general, if I'm using an FSM to control the timing of something, I
don't want to also use flags set by the FSM.
Or if I'm using flags to control the timing of something, I don't want
to also use the FSM state itself (especially if the FSM is the one
controlling the flags)
So, you could add a TXD_Delay state to replace the flag:
if (reset='1') then
act_txd_state := TXD_IDLE;
elsif (clk'event and clk ='1')
then
case act_txd_state is
when TXD_IDLE =>
if (txValid = '1') then
act_txd_state := TXD_ACTIVE;
end if;
when TXD_ACTIVE =>
if (txReady = '1') then
act_txd_state := TXD_DELAY;
end if;
when TXD_DELAY =>
act_txd_state := TXD_END;
when TXD_END =>
if (txValid = '0') then
act_txd_state :=
TXD_IDLE;
end if;
end case;
end if;
if (act_txd_state = TXD_ACTIVE) OR act_txd_state =
TXD_DELAY) then
if (dataIn = "00000000") then
tx_data <= "01000000";
else
tx_data <= "11000000";
end if;
elsif (act_txd_state = TXD_END) then
tx_data <= dataIn;
else
tx_data <= "00000000";
end if;
Or you could create a better flag that tells you exactly when to alter
or pass data_in, and not have to bother with decoding the FSM
elsewhere.
This is my favorite method, if the outputs cannot be coded directly in
the case statement for the FSM. It decouples the FSM state
transitions, etc. from the output logic. If you later need to add/
remove/change states (for error handling, etc.), your output logic
need not change.
Note that since the flag is only used in conditional statements, it is
easier to use if it is defined as a boolean. Of course, it could
probably use a more descriptive name too.
if (reset='1') then
act_txd_state := TXD_IDLE;
v_flag := false;
elsif (clk'event and clk ='1')
then
-- v_flag := '0'; -- get rid of this, we don't
want it defaulting back to 0
case act_txd_state is
when TXD_IDLE =>
if (txValid = '1') then
act_txd_state := TXD_ACTIVE;
v_flag := true;
end if;
when TXD_ACTIVE =>
if (txReady = '1') then
act_txd_state := TXD_END;
v_flag := false;
end if;
when TXD_END =>
if (txValid = '0') then
act_txd_state :=
TXD_IDLE;
end if;
end case;
end if;
-- Do you really need tx_data to be "00000000" at the end?
-- I'm going to assume that you really don't care what it is, right?
if v_flag then -- greatly simplified here & decoupled
from FSM design
if (dataIn = "00000000") then
tx_data <= "01000000";
else
tx_data <= "11000000";
end if;
-- elsif (act_txd_state = TXD_END) then
else
tx_data <= dataIn;
-- else
-- tx_data <= "00000000";
end if;
Of course, this last example also would be simple to split into a
separate, clocked process for FSM, and a combinatorial process for the
data path (v_flag would have to be a signal.) Here is a concurrent
assignment statement that would do the trick:
tx_data <= "01000000" when v_flag and data_in = "00000000"
else "11000000" when v_flag
else data_in;
Hope this helps,
Andy
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z