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
Joseph H Allen wrote: > In article <l3gq1p$ua8$1@dont-email.me>, > GaborSzakacs <gabor@alacron.com> wrote: >> Joseph H Allen wrote: >>> In article <l3d4aa$dmi$1@dont-email.me>, Gabor <gabor@szakacs.org> wrote: > >>>> reg [3:0] foo = 4'd7; > >>> Yeah I've been playing with this, it does work, but has the disadvantage >>> that your code will then be different from RTL for an ASIC.. I mean if you >>> used these initial values for all flops in the design, then you would not >>> need an explicit reset net at all. I'm pretty sure design compiler will not >>> support it. > > BTW, this syntax works for Synplify, but not for Lattice's new LSE. > > Also I discovered that switching between synthesis tools breaks the pin > assignments. > >>>> In all the years I've used Xilinx tools and FPGA's I don't think >>>> I ever actually assigned a package pin for a reset, although I >>>> typically have an internally generated reset net using a short >>>> shift register that initializes to all ones and shifts in zero >>>> after power-up. > >>> This means you will not be able to use the FPGA's already existing global >>> reset net in place of one which takes up routing resources. This one shift >>> register will prevent you from making the explicit reset net equal to the >>> built-in one (which only works if all flops in the entire design are >>> connected to the same net). > >>> Anyway, it's not such a big deal with the chips these days, but still it >>> would be nice if there was a way to do it. The initial value is a good way >>> to make an internal reset generator as you say. > >> Now that I think of it, Lattice has a way to use the global reset net >> internally. At least in the last parts I used (ECP and ECP2) you could >> do essentially the same business I did with Xilinx, and then tie the >> output of the shift register to the global reset net. The reason this >> works in Lattice and not Xiinx is that the Lattice parts allow you to >> remove the global reset function on a flop-by-flop basis. Thus you >> turn off global reset on the reset S/R itself. > > I found the part of Lattice's documentation which talks about this- it's > quite elborate (complex). It looks like the default is to use GSR for the > largest reset net, and disable it for any others. I'm surprised that they > found it worthwhile to add this configuration bit to every flop in the chip. > > I wonder if flops with GSR disabled are really in an indeterminate state out > of configuration... I guess it could be either way: if they clear the config > bit chain and hit the global reset before loading the design they would get > cleared.. > > > Here's a snippet of an ECP2 project. The "FD1P3AX" is a library element and it is reset to zero at configuration (this is an SRAM part like Xilinx). However it is not connected to the GSR net. Note that I also specify the GSR net, rather than get surprised when the ispLever software decides to connect it to some other net. I've been burned by that before. Remember in these parts, the configuration bitstream contains the initial value of all flops, which does not need to be the same as the reset value, but defaults to that. This also used to be true of Xilinx parts, but newer ones require an asynch reset to match the configuration init value. So in fact without GSR you still come up in a known state after configuration. This is not literally a "reset" function, but the equivalent of shifting the data into the flops during configuration. In the same way you can initialize all your BRAM and SRL's (yeah Lattice has those, too), even though they have no "reset" function. // -------------------------------------------------------------------- // Instantiate flip-flops for internal reset signals // This flip-flop comes up reset after configuration. FD1P3AX sysclk_rst_ff ( .D (1'b1), .SP (1'b1), .CK (sys_clock), .Q (sysclk_rstn) ); assign sys_reset = !sysclk_rstn; // Prevent GSR from resetting its own source: parameter DISABLED_GSR = "DISABLED"; defparam sysclk_rst_ff.GSR = DISABLED_GSR; GSR GSR_INST ( // Global set/reset is active low: .GSR (sysclk_rstn) ); -- GaborArticle: 155901
On 13/10/2013 05:18, rickman wrote: [] >> Apparently I have not found a 'global reset line' for the igloo family, >> but there's an interesting application note from Actel/Microsemi on >> their Flash-based devices which I find quite interesting: >> >> http://www.actel.com/documents/LPF_AC380_AN.pdf > > Wow, if Actel doesn't have a global reset line I have no idea how they > make their parts work. please do not take my words for granted. Maybe I haven't looked careful enough. OTOH I've worked with Actel components since a lot and found them very easy to handle (provided the board designer puts in a powerup reset circuitry!). > I haven't read the above app note, but the way > most brands of FPGAs work, there is a global reset line which holds the > user logic in reset until the end of config. This like is similar to a > global clock line, but without the high speed drive. When the reset is > released the entire chip can start. The problem is the delay on this > line is long enough to cause problems releasing the entire design on the > same clock cycle. They are 'live at power up' (LAPU). See here for more information: http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf (warning: it took me a long time to download the file even though the size is relatively small - 727KB) > > It is seldom that an entire FPGA design has to start on the same clock > edge. I design individual circuits to start up on a local copy of the > reset. Or better still is to design them so they start in an idle state > waiting for something else to happen which will take a clock cycle or > two providing enough delay that they don't need a synchronous reset. I agree with what Alan says: "Designing for all-IDLE FSMs is the proper approach but doesn't eliminate the need to have an explicit reset" >> it seems that 'weak pull-up/down' will be activated as soon as Vcc and >> Vcci are above functional threshold, which is essentially enough to have >> a logic '1' driven at the input of the POR proposed in the other note. > > Are you saying you have designed the board without consideration to > resetting the FPGA? I can't imagine the Actel parts require an external > reset. I'm glad I am finding this out now. I jumped in the project far after those details were left out of the design phase. How do you reset your logic only through the internal resources of your device?Article: 155902
On 10/13/2013 7:39 AM, Alan Reynolds wrote: > On 2013-10-13 03:18:43 +0000, rickman said: > >> On 10/11/2013 5:46 PM, alb wrote: >>> Hi Glen, >>> >>> On 11/10/2013 19:52, glen herrmannsfeldt wrote: >>> [] >>>>> My question here is the following: should I route the 'lock' >>>>> signal to a special buffer to minimize delays or would it be >>>>> sufficient to use it as is? >>>> >>>> First, I agree with what Mark says. >>> >>> and I also start to believe my reset strategy is weak! >>> >>>> In addition, note that most FPGA families have a global reset line >>>> similar to the global clock lines. They usually keep all the FF held >>>> at reset until configuration is done, and also allow you to use that >>>> reset line. It is there, it is free, and you might was well use it. >>> >>> Apparently I have not found a 'global reset line' for the igloo family, >>> but there's an interesting application note from Actel/Microsemi on >>> their Flash-based devices which I find quite interesting: >>> >>> http://www.actel.com/documents/LPF_AC380_AN.pdf >> >> Wow, if Actel doesn't have a global reset line I have no idea how they >> make their parts work. I haven't read the above app note, but the way >> most brands of FPGAs work, there is a global reset line which holds >> the user logic in reset until the end of config. This like is similar >> to a global clock line, but without the high speed drive. When the >> reset is released the entire chip can start. The problem is the delay >> on this line is long enough to cause problems releasing the entire >> design on the same clock cycle. > > Actel/Microsemi FPGAs are FLASH so don't need configuration. You have to > reset them in the same way you would an ASIC. I don't think that is relevant to the discussion. What you call it doesn't matter, the point is that the device must have some way to reset all the user FFs at power up and also when controlled by the user. In the Xilinx devices the problem comes from the fact that this global reset signal is not fast enough to assure all FFs are reset or released from reset in the same clock cycle. That is the issue. So do the Actel devices have a global reset/set signal? Is it fast enough to control all FFs in the same clock cycle? >> It is seldom that an entire FPGA design has to start on the same clock >> edge. I design individual circuits to start up on a local copy of the >> reset. Or better still is to design them so they start in an idle >> state waiting for something else to happen which will take a clock >> cycle or two providing enough delay that they don't need a synchronous >> reset. > > Designing for all-IDLE FSMs is the proper approach but doesn't eliminate > the need to have an explicit reset. Global resources are typically used > for the RESET even when timing is not an issue to remove the routing > burden of thousands of loads. The locally copied RESETs are usually only > useful if you need to support synchronous resets. Yes, I agree, but I don't get your point. I am discussing the global reset signal, does the Actel devices have one. The local resets are for things that *do* need to start up on the same clock cycle; call it a synchronous reset then. A free running state machine is a good example. A counter is another. -- RickArticle: 155903
On 10/14/2013 4:35 PM, alb wrote: > On 13/10/2013 05:18, rickman wrote: > [] >>> Apparently I have not found a 'global reset line' for the igloo family, >>> but there's an interesting application note from Actel/Microsemi on >>> their Flash-based devices which I find quite interesting: >>> >>> http://www.actel.com/documents/LPF_AC380_AN.pdf >> >> Wow, if Actel doesn't have a global reset line I have no idea how they >> make their parts work. > > please do not take my words for granted. Maybe I haven't looked careful > enough. OTOH I've worked with Actel components since a lot and found > them very easy to handle (provided the board designer puts in a powerup > reset circuitry!). I'm trying to understand what you *are* saying about the reset. Does Actel provide a mechanism so that each FF is brought out of reset on the same clock cycle? This makes a *big* difference in how you design your reset operation. I think you are saying the FPGA has an external reset pin which the board controls. Good. Does your board control that? What does the reset do on the FPGA exactly? >> I haven't read the above app note, but the way >> most brands of FPGAs work, there is a global reset line which holds the >> user logic in reset until the end of config. This like is similar to a >> global clock line, but without the high speed drive. When the reset is >> released the entire chip can start. The problem is the delay on this >> line is long enough to cause problems releasing the entire design on the >> same clock cycle. > > They are 'live at power up' (LAPU). See here for more information: > > http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf > > (warning: it took me a long time to download the file even though the > size is relatively small - 727KB) I don't care if they are live at power up. Is that relevant? I'm trying to understand the reset process. >> It is seldom that an entire FPGA design has to start on the same clock >> edge. I design individual circuits to start up on a local copy of the >> reset. Or better still is to design them so they start in an idle state >> waiting for something else to happen which will take a clock cycle or >> two providing enough delay that they don't need a synchronous reset. > > I agree with what Alan says: "Designing for all-IDLE FSMs is the proper > approach but doesn't eliminate the need to have an explicit reset" Maybe I don't understand what you are saying at all. Hopefully you will explain exactly what the problem is. Is there *no* reset to the FPGA on your board? >>> it seems that 'weak pull-up/down' will be activated as soon as Vcc and >>> Vcci are above functional threshold, which is essentially enough to have >>> a logic '1' driven at the input of the POR proposed in the other note. >> >> Are you saying you have designed the board without consideration to >> resetting the FPGA? I can't imagine the Actel parts require an external >> reset. I'm glad I am finding this out now. > > I jumped in the project far after those details were left out of the > design phase. How do you reset your logic only through the internal > resources of your device? So are you saying there is no external reset on the board for the FPGA? Why can't you add one? The need for this seems like a no-brainer even if it is a white wire job. If there is no reset, what can you know about the state of the FFs on powerup? If they are random, I don't think you can make this work without a power up reset. Ah! I went back to your initial post about the PLL lock signal. Assuming this signal is meaningful at all times I would expect it to be "unlock" (as opposed to "lock") at power up. If that is true then I think you can condition it to give you a reset to your logic. A small circuit consisting of a long period counter can be held in reset while the PLL is not locked. The rest of the design is held in reset by the counter. When the counter reaches its final state, implying the PLL lock signal has been valid long enough to actually indicate a true PLL lock, the reset to the rest of the logic is released. Maybe this is obvious to you. If so, I don't understand what your question is. To tell you the truth, I would try discussing this with an Actel FAE. Hopefully they know the answer. -- RickArticle: 155904
On 4/4/2013 6:20 PM, Mike Butts wrote: > Hi Paul, > > It's a plain XC3020. I installed a 2001 Student Edition on my Win7 machine, and it appears to run. All it needed was the license code that came with the CD-ROM. > > I'm pretty sure XC3020 and XC3020A differ only in timing and the same bitfile can work on both. Anyway I'll be finding out sometime soon and I'll post how it goes. > Thanks all! I take it you are on your way. I found my old Xilinx software *and* what I think are the dongles for it, a couple three of them. I believe the oldest version is Foundation 1.4, but I'm not sure as I seem to have left the box will it all at my other place. I actually promised this to someone so I need to find his email and tell him I can ship it if he is still interested. I also have a set of floppies with ViewLogic (if I remember the right name)... they *are* 3.5 inch floppies, not 5 1/4. :p -- RickArticle: 155905
Fix the issue with the help of a reply in the xilinx forum...I had to use s= w_sdk_repo for the custom repository folder for the sdk to see it correctly= ... On Monday, October 14, 2013 1:44:52 PM UTC+2, mormegil231 wrote: > Hello all, >=20 >=20 >=20 > I have been using Vivado HLS to create an IP to later use the rest of the= toolflow to implement a system using a Microblaze and the HLS IP. HLS acta= ully automatically creates drivers for programming the system and controlli= ng it through the Microblaze.I need to use this tooflow since i onyl have a= virtex 7 available and use 7-series only xilinx IPs. So to go by the old E= DK flow is not an option.=20 >=20 >=20 >=20 > These are supposed to be imported in SDK. the problem is that SDK do not = recognize the drivers and as such the IP in SDK is defined as having generi= c driver instead if its own. I did change the repository to point at the HL= S drivers but still i do not get the option to use the HLS driver.=20 >=20 >=20 >=20 > I am thinking that it is a naming issue...My IP's name is ComputeNetwork.= What I see is that in the MDD files the HLS IP adds in the naming of the s= upported peripherals version stuff... >=20 >=20 >=20 > http://img826.imageshack.us/img826/3314/1yl2.png >=20 >=20 >=20 >=20 >=20 > Yet the IDE and SDK see my IP just as a ComputeNetwork component: >=20 >=20 >=20 > http://img197.imageshack.us/img197/1047/4nmf.png >=20 >=20 >=20 >=20 >=20 > http://img62.imageshack.us/img62/5428/2fwx.png >=20 >=20 >=20 > Did not get any answers in the xilinx forum...Any ideas about the issue w= ill be greatly appreciated. >=20 >=20 >=20 > Thanks a lot, >=20 > GeorgeArticle: 155906
On 2013-10-15 01:59:34 +0000, rickman said: > On 10/14/2013 4:35 PM, alb wrote: >> On 13/10/2013 05:18, rickman wrote: >> [] >>>> Apparently I have not found a 'global reset line' for the igloo family, >>>> but there's an interesting application note from Actel/Microsemi on >>>> their Flash-based devices which I find quite interesting: >>>> >>>> http://www.actel.com/documents/LPF_AC380_AN.pdf >>> >>> Wow, if Actel doesn't have a global reset line I have no idea how they >>> make their parts work. >> >> please do not take my words for granted. Maybe I haven't looked careful >> enough. OTOH I've worked with Actel components since a lot and found >> them very easy to handle (provided the board designer puts in a powerup >> reset circuitry!). > > I'm trying to understand what you *are* saying about the reset. Does > Actel provide a mechanism so that each FF is brought out of reset on > the same clock cycle? This makes a *big* difference in how you design > your reset operation. Non-FLASH FPGAs have to be configured on power-on so the reseting of FFs is a by-product of that activity which allows for the deassertion of the configuration RESET *after* every FF has been configured to a known value. Like an ASIC, Actel parts require and explicit POR because they do not have a configuration sequence. If the POR signal (or logic output) is placed on a global net and your design frequency is below insertion delay plus skew of the global net and the POR is synchronously deasserted then every FF in the chip will be in the reset state in the same clock cycle. Again, this is the same consideration you have to use when reseting an ASIC. > > I think you are saying the FPGA has an external reset pin which the > board controls. Good. Does your board control that? What does the > reset do on the FPGA exactly? > > >>> I haven't read the above app note, but the way >>> most brands of FPGAs work, there is a global reset line which holds the >>> user logic in reset until the end of config. This like is similar to a >>> global clock line, but without the high speed drive. When the reset is >>> released the entire chip can start. The problem is the delay on this >>> line is long enough to cause problems releasing the entire design on the >>> same clock cycle. >> >> They are 'live at power up' (LAPU). See here for more information: >> >> http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf >> >> (warning: it took me a long time to download the file even though the >> size is relatively small - 727KB) > > I don't care if they are live at power up. Is that relevant? I'm > trying to understand the reset process. No configuration sequence means no global reset. > > >>> It is seldom that an entire FPGA design has to start on the same clock >>> edge. I design individual circuits to start up on a local copy of the >>> reset. Or better still is to design them so they start in an idle state >>> waiting for something else to happen which will take a clock cycle or >>> two providing enough delay that they don't need a synchronous reset. >> >> I agree with what Alan says: "Designing for all-IDLE FSMs is the proper >> approach but doesn't eliminate the need to have an explicit reset" > > Maybe I don't understand what you are saying at all. Hopefully you > will explain exactly what the problem is. Is there *no* reset to the > FPGA on your board? > > >>>> it seems that 'weak pull-up/down' will be activated as soon as Vcc and >>>> Vcci are above functional threshold, which is essentially enough to have >>>> a logic '1' driven at the input of the POR proposed in the other note. >>> >>> Are you saying you have designed the board without consideration to >>> resetting the FPGA? I can't imagine the Actel parts require an external >>> reset. I'm glad I am finding this out now. >> >> I jumped in the project far after those details were left out of the >> design phase. How do you reset your logic only through the internal >> resources of your device? > > So are you saying there is no external reset on the board for the FPGA? > Why can't you add one? The need for this seems like a no-brainer > even if it is a white wire job. > > If there is no reset, what can you know about the state of the FFs on > powerup? If they are random, I don't think you can make this work > without a power up reset. > > Ah! I went back to your initial post about the PLL lock signal. > Assuming this signal is meaningful at all times I would expect it to be > "unlock" (as opposed to "lock") at power up. If that is true then I > think you can condition it to give you a reset to your logic. > > A small circuit consisting of a long period counter can be held in > reset while the PLL is not locked. The rest of the design is held in > reset by the counter. When the counter reaches its final state, > implying the PLL lock signal has been valid long enough to actually > indicate a true PLL lock, the reset to the rest of the logic is > released. This is a perfectly reasonable approach and one that I have used when the stability of LOCK was a potential issue. > > Maybe this is obvious to you. If so, I don't understand what your question is. > > To tell you the truth, I would try discussing this with an Actel FAE. > Hopefully they know the answer.Article: 155907
In article <l3i913$1af$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:
>On 4/4/2013 6:20 PM, Mike Butts wrote:
>> Hi Paul,
>> It's a plain XC3020. I installed a 2001 Student Edition on my Win7 machine, and it
>appears to run. All it needed was the license code that came with the CD-ROM.
>> I'm pretty sure XC3020 and XC3020A differ only in timing and the same bitfile can work
>on both. Anyway I'll be finding out sometime soon and I'll post how it goes.
>> Thanks all!
>I take it you are on your way. I found my old Xilinx software *and*
>what I think are the dongles for it, a couple three of them. I believe
>the oldest version is Foundation 1.4, but I'm not sure as I seem to have
>left the box will it all at my other place.
I can confirm that Xilinx XACT runs on Windows-XP (with the dongle). You
can hand-edit your XC2064s :-)
Also, I remember that early versions of Foundation were tied to the
partition serial number in the MBR (which you can easily change with DOS
"debug" command). I mean the first versions which finally got rid of the
dongle.
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 155908Joseph H Allen wrote: > In article <l3i913$1af$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> On 4/4/2013 6:20 PM, Mike Butts wrote: >>> Hi Paul, > >>> It's a plain XC3020. I installed a 2001 Student Edition on my Win7 machine, and it >> appears to run. All it needed was the license code that came with the CD-ROM. > >>> I'm pretty sure XC3020 and XC3020A differ only in timing and the same bitfile can work >> on both. Anyway I'll be finding out sometime soon and I'll post how it goes. >>> Thanks all! > >> I take it you are on your way. I found my old Xilinx software *and* >> what I think are the dongles for it, a couple three of them. I believe >> the oldest version is Foundation 1.4, but I'm not sure as I seem to have >> left the box will it all at my other place. > > I can confirm that Xilinx XACT runs on Windows-XP (with the dongle). You > can hand-edit your XC2064s :-) > > Also, I remember that early versions of Foundation were tied to the > partition serial number in the MBR (which you can easily change with DOS > "debug" command). I mean the first versions which finally got rid of the > dongle. > I've got a copy of Foundation 1.3 (this one was also called XACT Step Foundation) on my bookshelf. I think that 2.1 was out by the time I actually started using Xilinx parts. I still have ViewDraw running on Windows XP as well as Foundation 4.1i. I think I was running NT 4.0 when I started with Xilinx tools. By then the oldest family I used was the XC4000 series and very soon moved on to Spartan, SpartanXL and Virtex. My copy of Foundation 4.1i does not support XC3000 series, but since there were options to include individual families when you install it I am not sure if that means that 4.1i doesn't support XC3000 or if I simply didn't install that in order to save some disk space at a time when a large hard drive was 5 GB. Since I started using Foundation, the license has been tied to the hard drive serial number, which is easily changed, and probably one of the reasons that Aldec sued Xilinx for delivering uncounted seats. The most recent Xilinx product licenses are tied to the MAC address which can also be changed on most add-in card based Ethernet controllers. Xilinx is also willing to re-target your license to a new PC, so there are many ways to cheat the seat count. -- GaborArticle: 155909
On 10/15/2013 8:34 AM, Alan Reynolds wrote: > On 2013-10-15 01:59:34 +0000, rickman said: > >> On 10/14/2013 4:35 PM, alb wrote: >>> On 13/10/2013 05:18, rickman wrote: >>> [] >>>>> Apparently I have not found a 'global reset line' for the igloo >>>>> family, >>>>> but there's an interesting application note from Actel/Microsemi on >>>>> their Flash-based devices which I find quite interesting: >>>>> >>>>> http://www.actel.com/documents/LPF_AC380_AN.pdf >>>> >>>> Wow, if Actel doesn't have a global reset line I have no idea how they >>>> make their parts work. >>> >>> please do not take my words for granted. Maybe I haven't looked careful >>> enough. OTOH I've worked with Actel components since a lot and found >>> them very easy to handle (provided the board designer puts in a powerup >>> reset circuitry!). >> >> I'm trying to understand what you *are* saying about the reset. Does >> Actel provide a mechanism so that each FF is brought out of reset on >> the same clock cycle? This makes a *big* difference in how you design >> your reset operation. > > Non-FLASH FPGAs have to be configured on power-on so the reseting of FFs > is a by-product of that activity which allows for the deassertion of the > configuration RESET *after* every FF has been configured to a known > value. Like an ASIC, Actel parts require and explicit POR because they > do not have a configuration sequence. If the POR signal (or logic > output) is placed on a global net and your design frequency is below > insertion delay plus skew of the global net and the POR is synchronously > deasserted then every FF in the chip will be in the reset state in the > same clock cycle. Again, this is the same consideration you have to use > when reseting an ASIC. Thanks. I don't need an explanation of what a Flash or RAM based FPGA is, I need to know what mechanism is provided in the Actel FPGAs for resetting all the FFs in your design on power up or external reset signal. Is there *any* specific resource for this? Or is it up to the synthesis tool to use the otherwise available routing? This makes it sound like there are no specific features to support reset of the FFs. I can't imagine there wouldn't be a clear explanation somewhere of how this is intended to be done. >> I think you are saying the FPGA has an external reset pin which the >> board controls. Good. Does your board control that? What does the >> reset do on the FPGA exactly? >> >> >>>> I haven't read the above app note, but the way >>>> most brands of FPGAs work, there is a global reset line which holds the >>>> user logic in reset until the end of config. This like is similar to a >>>> global clock line, but without the high speed drive. When the reset is >>>> released the entire chip can start. The problem is the delay on this >>>> line is long enough to cause problems releasing the entire design on >>>> the >>>> same clock cycle. >>> >>> They are 'live at power up' (LAPU). See here for more information: >>> >>> http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf >>> >>> (warning: it took me a long time to download the file even though the >>> size is relatively small - 727KB) >> >> I don't care if they are live at power up. Is that relevant? I'm >> trying to understand the reset process. > > No configuration sequence means no global reset. No, no configuration means no configuration. The global reset is an entirely separate feature. >>> I jumped in the project far after those details were left out of the >>> design phase. How do you reset your logic only through the internal >>> resources of your device? >> >> So are you saying there is no external reset on the board for the >> FPGA? Why can't you add one? The need for this seems like a no-brainer >> even if it is a white wire job. >> >> If there is no reset, what can you know about the state of the FFs on >> powerup? If they are random, I don't think you can make this work >> without a power up reset. >> >> Ah! I went back to your initial post about the PLL lock signal. >> Assuming this signal is meaningful at all times I would expect it to >> be "unlock" (as opposed to "lock") at power up. If that is true then I >> think you can condition it to give you a reset to your logic. >> >> A small circuit consisting of a long period counter can be held in >> reset while the PLL is not locked. The rest of the design is held in >> reset by the counter. When the counter reaches its final state, >> implying the PLL lock signal has been valid long enough to actually >> indicate a true PLL lock, the reset to the rest of the logic is released. > > This is a perfectly reasonable approach and one that I have used when > the stability of LOCK was a potential issue. It does not resolve the issue of how the reset reaches the rest of the FFs in the device. I find it hard to believe that there is no global reset feature in an Actel device. This means the general routing or possibly clock routing must be used. >> Maybe this is obvious to you. If so, I don't understand what your >> question is. >> >> To tell you the truth, I would try discussing this with an Actel FAE. >> Hopefully they know the answer. I remember when FAEs used to respond to posts here. But then some of them generated some rather bad press for their company with a rather confrontational style. -- RickArticle: 155910
On 10/15/2013 2:57 PM, GaborSzakacs wrote: > > The most recent Xilinx product licenses are tied to the MAC address > which can also be changed on most add-in card based Ethernet > controllers. Xilinx is also willing to re-target your license to > a new PC, so there are many ways to cheat the seat count. I am a one man company, so I never have incentive to "cheat the seat count". But this thread is exactly the issue I am concerned about with licensed software. Will it be supported some years down the road when I need it for an update? If it were FOSS, I would know the answer. But so far I have found commercial software to be tied to the bucks it can generate for the developers in the future, not the bucks you have paid in the past. This is the one reason I can see in favor of pushing for FOSS FPGA software. But unfortunately the ones pushing are a very small force compared to the overall market so that they have *no* influence in the direction of FPGA development software... at least in terms of being supported by the FPGA vendors. -- RickArticle: 155911
On Sat, 05 Oct 2013 04:23:27 +0000, Joseph H Allen wrote: >>Hmm... I'm pretty sure this won't work. The synthesizer will again >>complain that the wire is driven from multiple sources. But I'll give it >>a try. > > I just tried it in LSE- it works fine. Also it tri-state works. Make > sure you are assigning like this: > > assign bus = enable ? signal : 4'bzzzz; > > It also works to have module outputs connected directly to a wor or > tri-state bus. Annoyingly, this does not work in Altera Quartus-II. I've only now found time to try this. And it works! What happened previously was that I assigned like this: assign bus = enable ? signal : 8'hz; Turns out you _do_ need to 'z every bit. Unfortunately, the bidir bus did not live up to my expectations. Basically, yes, it reduces the number of SLICEs used, but only marginally and not always, depending on other details (like the one below). I found a different way to free up space: use the internal clock. MachXO2 comes with an internal oscillator and using this instead of an other clock source can easily slash high tens of SLICEs off. I don't know exactly why this happens, the only thing I can assume is that many of those SLICEs are used for synchronization or normalization or something else that doesn't need to be done with the onboard clock.Article: 155912
On 10/15/2013 8:43 PM, Aleksandar Kuktin wrote: > On Sat, 05 Oct 2013 04:23:27 +0000, Joseph H Allen wrote: > >>> Hmm... I'm pretty sure this won't work. The synthesizer will again >>> complain that the wire is driven from multiple sources. But I'll give it >>> a try. >> >> I just tried it in LSE- it works fine. Also it tri-state works. Make >> sure you are assigning like this: >> >> assign bus = enable ? signal : 4'bzzzz; >> >> It also works to have module outputs connected directly to a wor or >> tri-state bus. Annoyingly, this does not work in Altera Quartus-II. > > I've only now found time to try this. And it works! What happened > previously was that I assigned like this: > > assign bus = enable ? signal : 8'hz; > > Turns out you _do_ need to 'z every bit. Generally I don't use hexadecimal for tristates. I have always found that 8'bz is the same as 8'bzzzzzzzz. Remember that if you size the tristate constant too small (e.g. 4'bz for an 8-bit reg) then it gets _zero_ extended as required by the LRM. > > Unfortunately, the bidir bus did not live up to my expectations. > Basically, yes, it reduces the number of SLICEs used, but only marginally > and not always, depending on other details (like the one below). > > I found a different way to free up space: use the internal clock. MachXO2 > comes with an internal oscillator and using this instead of an other > clock source can easily slash high tens of SLICEs off. I don't know > exactly why this happens, the only thing I can assume is that many of > those SLICEs are used for synchronization or normalization or something > else that doesn't need to be done with the onboard clock. > huh? I would have thought that the slice usage would be the same for any clock source. You might use some slices for reset and lock detection if you add a PLL for the external clock. But just running a pin to a global clock buffer shouldn't use any slice resources. That being said, I've seen large differences in slice usage for the exact same design built with different placements. Much of this is due to LUTs used as route-throughs or differences in slice packing. I'd check the LUT and register count rather than slices before giving any credence to the idea that an external clock source adds to logic usage. -- GaborArticle: 155913
On 10/15/2013 10:10 PM, Gabor wrote: > On 10/15/2013 8:43 PM, Aleksandar Kuktin wrote: >> >> Unfortunately, the bidir bus did not live up to my expectations. >> Basically, yes, it reduces the number of SLICEs used, but only marginally >> and not always, depending on other details (like the one below). >> >> I found a different way to free up space: use the internal clock. MachXO2 >> comes with an internal oscillator and using this instead of an other >> clock source can easily slash high tens of SLICEs off. I don't know >> exactly why this happens, the only thing I can assume is that many of >> those SLICEs are used for synchronization or normalization or something >> else that doesn't need to be done with the onboard clock. >> > > huh? I would have thought that the slice usage would be the same > for any clock source. You might use some slices for reset and > lock detection if you add a PLL for the external clock. But just > running a pin to a global clock buffer shouldn't use any slice > resources. That being said, I've seen large differences in slice > usage for the exact same design built with different placements. > Much of this is due to LUTs used as route-throughs or differences > in slice packing. I'd check the LUT and register count rather > than slices before giving any credence to the idea that an external > clock source adds to logic usage. This whole thread is a bit silly. There are *no* internal tristates in FPGAs released in the last 10 years, possibly 15 years. The simulator is showing tristates because that is what the code describes. Synthesis is turning this into multiplexers inside the FPGA. I can't say anything about the "slice" usage because slices are not the primitive elements in even a Xilinx FPGA, rather slices have multiple components which all get used in different ways including just for routing. If any part of a slice is used the slice is counted as used. This doesn't mean more logic can't be included... in other words, the slice utilization could be as high as 100% and you can still add more logic to your design. So counting slice usage isn't really telling you the story you want to know about. Try looking at the synthesis tool. Often they give a schematic view of exactly what logic was generated. I believe this is called "Technology View" in the tool I use for Lattice parts. Then you can see exactly how they are implementing your HDL code. Personally I would prefer to code for multiplexers because then you have some control over how it is implemented. In some logic devices other than Xilinx, muxes are more efficiently implemented as the cascaded AND of ORs rather than the traditional OR of ANDs, product of sums vs. sum of products if you will. Coding to the hardware can help the tool get to an efficient solution, but not if you are imagining internal logic that doesn't exist. -- RickArticle: 155914
rickman wrote: > I am a one man company, so I never have incentive to "cheat the seat > count". But this thread is exactly the issue I am concerned about with > licensed software. Will it be supported some years down the road when I > need it for an update? I think this problem has been simplified by the advancements in virtualization in recent years. At the company where I used to work, we had virtual machines with old Windows releases and old tools versions, and someone was clever enough to migrate the licenses for the old tools to those VMs before it was too late. The VMs themselves you can just copy from one PC to another if you upgrade your hardware. They had some issues with old parallel port dongles (since which PC has a parallel port nowadays?), but there's add-pon cards for that. So at least there's a working version of all the tools needed for older projects. > This is the one reason I can see in favor of pushing for FOSS FPGA > software. But unfortunately the ones pushing are a very small force > compared to the overall market so that they have *no* influence in the > direction of FPGA development software... at least in terms of being > supported by the FPGA vendors. Exactly. I personally don't think this is ever going to go anywhere. Even if there was enough manpower to design a decent toolset from the ground up (which there isn't, since the people who have the capabilities and know-how usually work for one of the vendors), vendors would have to disclose too many architecture internals and such, which is not going to happen (maybe they'd release that info for FPGA families that have been out of production for years but not current ones). I can imagine a University putting something together, but something like that usually stays at the 0.0011alpha release state forever once the PhDs it's based on are finished. In general, for a project this size and type FOSS rarely works, IMHO. It can work if the community can get an existing code base and improve it (like it happened for Mozilla and OpenOffice), but not if it's to be a project of this size and started from the ground up. Especially if it's something that doesn't "interest" a lot of people. After all, this is a niche (compared to something like the Gimp which potentially has millions and millions of users), so there's just not that many people likely to participate in the first place. This wouldn't be something that everyone(TM) uses, and it's way too big for a single person or small group of people to make any useful progress. So, no, I don't think OS EDA tools are ever going to happen. At least not something really useful... Unless one of the vendors decides to release the source code for their tools. But why should they? CU, SeanArticle: 155915
On Wednesday, 2 November 2011 17:25:33 UTC+10, lexuancong wrote: > hi ! > > im from vietnam . my english is not good , i hope you can understand > > what i say . thanks ! > > i have project to graduate university . > > my project is draw circle , line , triagle in FPGA , display on VGA > > ( only use verilog , don't use C) . i have many problems , and time is > > running out . if you have data , code about it , please help me. > > .... > > thanks you so much ! Hi I am in the same situation with the same project. can u please help meArticle: 155916
Hi Rick, On 15/10/2013 03:59, rickman wrote: [] >>> Wow, if Actel doesn't have a global reset line I have no idea how they >>> make their parts work. >> please do not take my words for granted. Maybe I haven't looked careful >> enough. OTOH I've worked with Actel components since a lot and found >> them very easy to handle (provided the board designer puts in a powerup >> reset circuitry!). > > I'm trying to understand what you *are* saying about the reset. Does > Actel provide a mechanism so that each FF is brought out of reset on the > same clock cycle? This makes a *big* difference in how you design your > reset operation. No. You need to take care of it on your own, externally (with dedicated circuitry) and internally (with dedicated logic). > I think you are saying the FPGA has an external reset pin which the > board controls. Good. Does your board control that? What does the > reset do on the FPGA exactly? In the design I'm working on there's no external reset circuitry on the pcb and no pin is reserved for this purpose except for an 'init' pin which can be activated upon certain conditions which, as of now, do not include power on. I've not yet found any dedicated pin and/or buffer to route the reset in the IGLOO family. >>> I haven't read the above app note, but the way >>> most brands of FPGAs work, there is a global reset line which holds the >>> user logic in reset until the end of config. This like is similar to a >>> global clock line, but without the high speed drive. When the reset is >>> released the entire chip can start. The problem is the delay on this >>> line is long enough to cause problems releasing the entire design on the >>> same clock cycle. >> >> They are 'live at power up' (LAPU). See here for more information: >> >> http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf >> >> (warning: it took me a long time to download the file even though the >> size is relatively small - 727KB) > > I don't care if they are live at power up. Is that relevant? I'm > trying to understand the reset process. I mentioned the 'live at power up' feature to refer to the fact that they *do not need* a configuration. >>> It is seldom that an entire FPGA design has to start on the same clock >>> edge. I design individual circuits to start up on a local copy of the >>> reset. Or better still is to design them so they start in an idle state >>> waiting for something else to happen which will take a clock cycle or >>> two providing enough delay that they don't need a synchronous reset. >> >> I agree with what Alan says: "Designing for all-IDLE FSMs is the proper >> approach but doesn't eliminate the need to have an explicit reset" > > Maybe I don't understand what you are saying at all. Hopefully you will > explain exactly what the problem is. Is there *no* reset to the FPGA on > your board? Correct, there's *no* reset to the FPGA on my board. [] >> I jumped in the project far after those details were left out of the >> design phase. How do you reset your logic only through the internal >> resources of your device? > > So are you saying there is no external reset on the board for the FPGA? > Why can't you add one? The need for this seems like a no-brainer even > if it is a white wire job. A white wire job will not help you since you need at least an RC pulled-up to Vcc and C might be the equivalent of 4 caps (a series of two parallel ones) to avoid single point failure and hold the FPGA in reset state permanently upon a short fault on the cap. Besides, we are about to enter flight module production (it's a space application) and we cannot functionally deviate from the qualification module (at least this are the rules we have to follow). > If there is no reset, what can you know about the state of the FFs on > powerup? If they are random, I don't think you can make this work > without a power up reset. In the AN I posted there's a solution the vendor proposes to implement a POR. They suggest to rely on an external weak pull-up and profit of the different time for input/output configuration during a power-up sequence. I do not have an external pull-up, but I/Os can be opted with a weak pull-up and maybe the result is the same. [] > A small circuit consisting of a long period counter can be held in reset > while the PLL is not locked. The rest of the design is held in reset by > the counter. When the counter reaches its final state, implying the PLL > lock signal has been valid long enough to actually indicate a true PLL > lock, the reset to the rest of the logic is released. I'll set the counter to count the maximum lock time as specified in the datasheet and I should be good to go. Synchronous release of the reset line should make it simple to perform STA on the reset line and let the P&R meet the time constraints. > Maybe this is obvious to you. If so, I don't understand what your > question is. In the OP, I was asking whether I should route the reset signal (currently coming from the 'lock' signal on the pll) to a special global net to avoid timing issues. After my post, Mark pointed out how unreliable are 'lock' signals from PLL and hence the whole discussion. > To tell you the truth, I would try discussing this with an Actel FAE. > Hopefully they know the answer. That is a valid suggestion, I used to believe that places like this one would have been good ones to get an answer from an FAE, <rant mode on> but it seems those days are gone and companies tend to continue to lock in users within their closed circles <rant mode off>.Article: 155917
On Wednesday, January 3, 2007 9:20:30 PM UTC+2, Clark Pope wrote: > Does anyone have any example code that uses the Xilinx SPI Linux driver? I > just need to read a temperature sensor so something simple that opens the > device and does read and writes should work. > > Thanks, > Clark Hi Is there anyway you can post the example? ThanksArticle: 155918
On 10/16/2013 3:33 AM, Sean Durkin wrote: > rickman wrote: >> I am a one man company, so I never have incentive to "cheat the seat >> count". But this thread is exactly the issue I am concerned about with >> licensed software. Will it be supported some years down the road when I >> need it for an update? > I think this problem has been simplified by the advancements in > virtualization in recent years. At the company where I used to work, we > had virtual machines with old Windows releases and old tools versions, > and someone was clever enough to migrate the licenses for the old tools > to those VMs before it was too late. The VMs themselves you can just > copy from one PC to another if you upgrade your hardware. They had some > issues with old parallel port dongles (since which PC has a parallel > port nowadays?), but there's add-pon cards for that. So at least there's > a working version of all the tools needed for older projects. You are talking about one particular licensing scheme for one, very old product. The licenses used on newer software work off of a software key that is tied to some aspect of your PC but more importantly, must be renewed each year regardless. If they stop renewing the license, you are stuck. >> This is the one reason I can see in favor of pushing for FOSS FPGA >> software. But unfortunately the ones pushing are a very small force >> compared to the overall market so that they have *no* influence in the >> direction of FPGA development software... at least in terms of being >> supported by the FPGA vendors. > Exactly. I personally don't think this is ever going to go anywhere. > Even if there was enough manpower to design a decent toolset from the > ground up (which there isn't, since the people who have the capabilities > and know-how usually work for one of the vendors), vendors would have to > disclose too many architecture internals and such, which is not going to > happen (maybe they'd release that info for FPGA families that have been > out of production for years but not current ones). It is *not* a matter of designing a *decent* toolset. The problem is the FPGA vendors don't release the information required to use their devices without their proprietary software. You simply *can't* roll your own FPGA development package end to end. It would be like writing a compiler for a CPU with no info on the instruction set. > I can imagine a University putting something together, but something > like that usually stays at the 0.0011alpha release state forever once > the PhDs it's based on are finished. There *are* FOSS HDL synthesis and simulation tools. I don't know, but I doubt there are FOSS place and route tools or timing analysis. The part that you just can't do without a *huge* reverse engineering effort is generating the bit stream file. > In general, for a project this size and type FOSS rarely works, IMHO. It > can work if the community can get an existing code base and improve it > (like it happened for Mozilla and OpenOffice), but not if it's to be a > project of this size and started from the ground up. Especially if it's > something that doesn't "interest" a lot of people. After all, this is a > niche (compared to something like the Gimp which potentially has > millions and millions of users), so there's just not that many people > likely to participate in the first place. This wouldn't be something > that everyone(TM) uses, and it's way too big for a single person or > small group of people to make any useful progress. > > So, no, I don't think OS EDA tools are ever going to happen. At least > not something really useful... Unless one of the vendors decides to > release the source code for their tools. But why should they? *That's* a bit extreme. There are ***tons*** of FOSS EDA tools available, as I mentioned, even HDL tools. It is just the final part that requires intimate knowledge of the chips that is not so feasible to develop. -- RickArticle: 155919
On 10/16/2013 4:02 AM, alb wrote: > Hi Rick, > > On 15/10/2013 03:59, rickman wrote: > [] >>>> Wow, if Actel doesn't have a global reset line I have no idea how they >>>> make their parts work. >>> please do not take my words for granted. Maybe I haven't looked careful >>> enough. OTOH I've worked with Actel components since a lot and found >>> them very easy to handle (provided the board designer puts in a powerup >>> reset circuitry!). >> >> I'm trying to understand what you *are* saying about the reset. Does >> Actel provide a mechanism so that each FF is brought out of reset on the >> same clock cycle? This makes a *big* difference in how you design your >> reset operation. > > No. You need to take care of it on your own, externally (with dedicated > circuitry) and internally (with dedicated logic). > >> I think you are saying the FPGA has an external reset pin which the >> board controls. Good. Does your board control that? What does the >> reset do on the FPGA exactly? > > In the design I'm working on there's no external reset circuitry on the > pcb and no pin is reserved for this purpose except for an 'init' pin > which can be activated upon certain conditions which, as of now, do not > include power on. > > I've not yet found any dedicated pin and/or buffer to route the reset in > the IGLOO family. > >>>> I haven't read the above app note, but the way >>>> most brands of FPGAs work, there is a global reset line which holds the >>>> user logic in reset until the end of config. This like is similar to a >>>> global clock line, but without the high speed drive. When the reset is >>>> released the entire chip can start. The problem is the delay on this >>>> line is long enough to cause problems releasing the entire design on the >>>> same clock cycle. >>> >>> They are 'live at power up' (LAPU). See here for more information: >>> >>> http://www.zlgmcu.com/Microsemi/SOC/igloo/LAPU_PIB.pdf >>> >>> (warning: it took me a long time to download the file even though the >>> size is relatively small - 727KB) >> >> I don't care if they are live at power up. Is that relevant? I'm >> trying to understand the reset process. > > I mentioned the 'live at power up' feature to refer to the fact that > they *do not need* a configuration. > >>>> It is seldom that an entire FPGA design has to start on the same clock >>>> edge. I design individual circuits to start up on a local copy of the >>>> reset. Or better still is to design them so they start in an idle state >>>> waiting for something else to happen which will take a clock cycle or >>>> two providing enough delay that they don't need a synchronous reset. >>> >>> I agree with what Alan says: "Designing for all-IDLE FSMs is the proper >>> approach but doesn't eliminate the need to have an explicit reset" >> >> Maybe I don't understand what you are saying at all. Hopefully you will >> explain exactly what the problem is. Is there *no* reset to the FPGA on >> your board? > > Correct, there's *no* reset to the FPGA on my board. > > [] >>> I jumped in the project far after those details were left out of the >>> design phase. How do you reset your logic only through the internal >>> resources of your device? >> >> So are you saying there is no external reset on the board for the FPGA? >> Why can't you add one? The need for this seems like a no-brainer even >> if it is a white wire job. > > A white wire job will not help you since you need at least an RC > pulled-up to Vcc and C might be the equivalent of 4 caps (a series of > two parallel ones) to avoid single point failure and hold the FPGA in > reset state permanently upon a short fault on the cap. > > Besides, we are about to enter flight module production (it's a space > application) and we cannot functionally deviate from the qualification > module (at least this are the rules we have to follow). > >> If there is no reset, what can you know about the state of the FFs on >> powerup? If they are random, I don't think you can make this work >> without a power up reset. > > In the AN I posted there's a solution the vendor proposes to implement a > POR. They suggest to rely on an external weak pull-up and profit of the > different time for input/output configuration during a power-up > sequence. I do not have an external pull-up, but I/Os can be opted with > a weak pull-up and maybe the result is the same. > > [] >> A small circuit consisting of a long period counter can be held in reset >> while the PLL is not locked. The rest of the design is held in reset by >> the counter. When the counter reaches its final state, implying the PLL >> lock signal has been valid long enough to actually indicate a true PLL >> lock, the reset to the rest of the logic is released. > > I'll set the counter to count the maximum lock time as specified in the > datasheet and I should be good to go. Synchronous release of the reset > line should make it simple to perform STA on the reset line and let the > P&R meet the time constraints. > >> Maybe this is obvious to you. If so, I don't understand what your >> question is. > > In the OP, I was asking whether I should route the reset signal > (currently coming from the 'lock' signal on the pll) to a special global > net to avoid timing issues. After my post, Mark pointed out how > unreliable are 'lock' signals from PLL and hence the whole discussion. > >> To tell you the truth, I would try discussing this with an Actel FAE. >> Hopefully they know the answer. > > That is a valid suggestion, I used to believe that places like this one > would have been good ones to get an answer from an FAE,<rant mode on> > but it seems those days are gone and companies tend to continue to lock > in users within their closed circles<rant mode off>. Ok, I think I understand the problem now. The fact that you are working on a space application makes it more clear why you are using an Actel part. I think space applications are what kept Actel alive for so many years. So you have a poor hardware design that you can't change and you are looking for some trick within the FPGA to generate a power on reset. I'm still not clear on why you can't use the PLL lock signal with conditioning. If the PLL lock signal is deasserted at power on, there is your power on reset. Then you simply need to condition it well enough to properly control exit from reset reliably. Am I still missing something? -- RickArticle: 155920
On 16.10.2013 09:39, ajbhavana89@gmail.com wrote: >> i have project to graduate university . >> my project is draw circle , line , triagle in FPGA , display on VGA >> ( only use verilog , don't use C) . i have many problems , and time is >> running out . if you have data , code about it , please help me. > Hi I am in the same situation with the same project. can u please help me Implement a simple CPU on the FPGA and do the drawing in software.Article: 155921
I'd like to pick people's brains about aspects of
different *suppliers* of Zynq boards. Avnet and Digilent
are front-runners, but any info/opinions about other
suppliers would be helpful too.
- ease of using their embedded linux. My needs
are simple, requiring a shell and TCP/IP protocols
over ethernet. GUI not required, but might be
used if it didn't complicate the development.
- quality of online support. How easy is it
likely to be to find the information so that
I can (a) duplicate any supplied demo environment
and (b) mutate it so that my code accesses my
programmable logic
- board production longevity. I'm not concerned
about decades, but I would be concerned if a
board was unobtainable within months
- ISE or Vivado environment
Background and context...
I'm intending to develop something based around a small
Xylinx Zynq device. Cost is an issue, but not to the
extent that I will be developing a board containing
the FPGA itself. I will, however, be developing a small
simple add-on board containing my analogue circuits.
Now I can read a datasheet and schematic and outline
to determine the extent to which a board is suitable.
However, as we are all aware, those documents /don't/
cover all the important points when choosing a board!
I've created many stand-alone hardware and software
embedded systems, but *not* based on linux *nor* on ARM
*nor* in the Xilinx ecosystem. Since Zynq devices
represent a complex environment, I'll have a learning
curve (good, I like challenges), and I'm interested
in the quality of the resources and support that
I'll need to overcome my misapprehensions.
Article: 155922Tom Gardner wrote: > I'd like to pick people's brains about aspects of > different *suppliers* of Zynq boards. Avnet and Digilent > are front-runners, but any info/opinions about other > suppliers would be helpful too. If you don't need it now, you might take a look at the Parallella board: http://www.parallella.org Currently they have some issues with EOL parts and re-designing parts of the board, so it will be delayed a bit. But I guess there are not much boards with the Zynq chip for $99, and you get a lot of peripherals, too, and of course the Epiphany coprocessor. And the Zynq chip used on the Parallella board is supported by the free Xilinx ISE version: http://forums.parallella.org/viewtopic.php?f=23&t=134 Linux is already working for the board (Ubuntu, well, you can't have anything, but should be not too difficult to port Debian for it). Even if you don't use it for your project later, might be a good starting point to learn to program the Zynq. -- Frank Buss, http://www.frank-buss.de electronics and more: http://www.youtube.com/user/frankbussArticle: 155923
rickman wrote: > You are talking about one particular licensing scheme for one, very old > product. The licenses used on newer software work off of a software key > that is tied to some aspect of your PC but more importantly, must be > renewed each year regardless. If they stop renewing the license, you > are stuck. You are right about that. But in all the cases I am familiar with you could switch to perpetual licenses when support was dropped (which you were informed of in a timely manner). The main problem was then having a machine the tools still run on. > It is *not* a matter of designing a *decent* toolset. The problem is > the FPGA vendors don't release the information required to use their > devices without their proprietary software. You simply *can't* roll > your own FPGA development package end to end. It would be like writing > a compiler for a CPU with no info on the instruction set. That is what I was saying. Still there's more to writing a USABLE toolset than just having the necessary information. I doubt that even if Xilinx would release all the specs, we'd ever get a DECENT, usable FOSS toolset. That kind of complex work requires coordinated effort, something that obviously not even the vendors with dedicated, big development teams can muster, let alone keep up to date with the ever-evolving chip technology. That is not the kind of project suitable to the OSS "community"-based design flow (there's exceptions, see below). > There *are* FOSS HDL synthesis and simulation tools. I don't know, but > I doubt there are FOSS place and route tools or timing analysis. The > part that you just can't do without a *huge* reverse engineering effort > is generating the bit stream file. Not that I'm aware of, except maybe some highly experimental stuff based on obsolete parts. In other words: useless, except for academic fiddling. > *That's* a bit extreme. There are ***tons*** of FOSS EDA tools > available, as I mentioned, even HDL tools. And that's exactly the problem. Tons of different tools, but nothing that is really useful (well, ghdl maybe... and if you wanna count Emacs VHDL mode as an EDA tool...). IMHO that's a general problem of FOSS. You can find some tool for almost EVERYTHING, but usually it stays in the state where it does exactly what the person who started it needed at one point, but nothing else. Then another person, who isn't content with what's available, starts another project, and so on. In the end you have a dozen tools that satisfy the needs of their respective creators, but are more or less useless to the rest of humankind. So if you don't have the time or know-how to improve the tools yourself, you're screwed. But you can't complain, since you can't look a gift hourse in the mouth... I've been using Linux for 15 years, and of course a lot of FOSS, and there's wonderful software out there far surpassing anything commercially available. But IMHO OSS really only works well in these cases: 1. small tools that can be handled by one enthusiastic person or a small group of people in their spare time 2. tools/services that big companies are pushing (like Red Hat or Google), meaning they put a decent-sized development team on it and pay it to work on that 3. projects that are based on an existing commercial product's source code (see OpenOffice and the like), or were developed commercially and then released to the public for whatever reason 4. projects that have many, many (potential) users and a lot of paid professional people chipping in (like the Linux kernel, the GCC suite, Gnome or KDE) EDA tools fit NONE of the above. And in cases like that you typically end up with tons of half-baked tools. As long as vendors provide free licenses for their tools at least for hobbyist use, there's really no incentive for hobbyists to invest their time and work in FOSS EDA tools. I'm saying hobbyists, since the pros work for one of the vendors anyway and/or don't have the need for FOSS because they have licenses for the commercial tools. And all of this applies even if all the required information was available, which it is not. On projects like that you never seem to see any real progress, because a) there's not enough manpower, b) there's not enough incentive and c) they soon hit the wall where they can't get the information they need. You are of course right that it would be nice to have FOSS tools to rely on for eternity, but as you said the number of people really needing that is small, way too small to get anything accomplished, really. So I'm sticking with what I said before: I don't see it happening, ever. Not for a toolchain for the complete flow, and one that goes beyond cryptic command-line tools that work in only 30% of applications. cu, SeanArticle: 155924
Hi Rick,
On 16/10/2013 10:29, rickman wrote:
[]
> Ok, I think I understand the problem now. The fact that you are working
> on a space application makes it more clear why you are using an Actel
> part. I think space applications are what kept Actel alive for so many
> years.
and automotive, avionics, defense, just to mention a few more.
> So you have a poor hardware design that you can't change and you are
> looking for some trick within the FPGA to generate a power on reset.
correct.
> I'm
> still not clear on why you can't use the PLL lock signal with
> conditioning. If the PLL lock signal is deasserted at power on, there
> is your power on reset. Then you simply need to condition it well
> enough to properly control exit from reset reliably.
>
> Am I still missing something?
Maybe you missed what I wrote in my previous post in reply to your
suggestion, so I'll paste it here for your convenience:
> I'll set the counter to count the maximum lock time as specified in the
> datasheet and I should be good to go. Synchronous release of the reset
> line should make it simple to perform STA on the reset line and let the
> P&R meet the time constraints.
Exactly as you proposed but specifying the length of the counter.
Indeed there's even a more subtle detail to add: since I do not know
what is the state of the lock signal at power up, my counter should have
a fixed value at reset and start to count when lock signal is deasserted
if and only if the fixed value of the counter is present. In this way I
can guarantee that a lock signal which is undefined at the beginning
does not allow the counter to start from a random position and hit the
target value too early. Something along these lines:
<code: not tested!>
-- rst is the lock signal from PLL
process (clk, rst)
if rst = '0' then
counter <= "101001000000"; -- 6 bit counter + 6 bit check
global_rst <= '0'; -- active low reset
elsif rising_edge(clk) then
if counter (11 downto 6) = "101001" then
counter <= counter + 1;
elsif counter (6) = '0' then
global_rst <= '1';
end if;
end if;
end process;
</code>
I'm not sure the synthesis will prune the upper end of the bits, so I
might need to do something more clever, but the upper part of the
counter is to verify that it did have a proper reset signal at some point.
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