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
My tristate signals are not being placed in the IOBs. They are clocked signals, always all on or all off, depending on reading or writing, and the registration happens the fabric, not in the IOB. The data_out signals are registered in the IOB's correctly. I have had this issue before with ISE7.1 and now again with 9.2. In the Synthesis properties under Xilinx Specific Options I changed the defaults Registration Duplication to check and the Pack I/O Registers into IOBs to Yes. No effect. I really don't want these options anyway. I really only want the tristate signals properly placed in the IOBs along with the data out signals. The defaults should be OK elsewhere. Can anyone help? Brad Smallridge AiVision.comArticle: 130101
On 13 Mrz., 17:24, "MM" <mb...@yahoo.com> wrote: > All that you could save would be object or executable file size. That is not true. The methods to find equivalent signals in circuits are much more sophisticated compared to the methods to find common subexpressions in software albeit the problems are very similar. I am also confident that there are more loop invariants than current compilers are able to find. Both are speed optimizations, not code size optimizations.Article: 130102
You haven't stated how long the signal needs to stay nor your clock frequency. You are right about option 2 needing less logic, never thought of that, and if you are working in Xilinx then you may get a nice 16 to one compression in your register use when the synthesizer packs your registers into an SRL16, although I'm not sure you can reset all the internal flip-flops. The most conventional solution is a counter that counts to your desired time and triggers. Brad Smallridge AiVision "M. Hamed" <mhs000@gmail.com> wrote in message news:a253f190-eff0-4e54-9e09-a3505f1e6c5f@s19g2000prg.googlegroups.com... >I have an input signal that is required to be high for a certain > length in time before a halt request is issued to a processor. To > detect this signal, three solutions popped into my head. > > 1- A shift register with all bits ANDed together. The output is taken > from the AND gate and will not be high unless the signal has passed > completely through the pipeline without going to zero(except for any > glitches that wasn't captured by the first FF. > > 2- A shift register with the Reset line (active low) of all the FFs > tied to to the signal. The output is taken from the last FF. In such a > case the last FF will never be 1 unless the signal was high for the > whole period while passing through the entire pipeline. If it goes to > zero any time before that, then all FFs (and hence the last FF) will > be zero. This solution may be more elegant than the first since it > doesn't really matter how long the pipeline is, while in the first, > the more stages, the bigger the AND gate. It would also detect any > glitches on the signal. > > 3- Divide the master clock using a binary counter until the desired > time length is achieved, then use a variation of the previous two > schemes but with a much reduced shift register length. > > Which solution would you choose? Are there any better approaches? I > would personally choose the third solution combined with the second, > since it means fewer FFs can be used for longer required times, and > any glitches will invalidate the pipeline. > > Thank you!Article: 130103
On Mar 14, 3:28=A0pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> wrote: > My tristate signals are not being placed > in the IOBs. They are clocked signals, > always all on or all off, depending on > reading or writing, and the registration > happens the fabric, not in the IOB. The > data_out signals are registered in the > IOB's correctly. > > I have had this issue before with ISE7.1 > and now again with 9.2. In the Synthesis > properties under Xilinx Specific Options > I changed the defaults Registration > Duplication to check and the Pack I/O > Registers into IOBs to Yes. No effect. > > I really don't want these options anyway. > I really only want the tristate signals > properly placed in the IOBs along with > the data out signals. The defaults should > be OK elsewhere. > > Can anyone help? > > Brad Smallridge > AiVision.com You need to check the compatibility of the control and clock signals that may be common resources in the IOB between the output register and the tristate register. Any conflict will mess up the packing before the synthesizer contemplates proper replication for bussed signals. I'd go straight to FPGA_Editor for this information. If you don't find a conflict that *would* keep these from packing, try using the IOB=3DTRUE attribute applied to the tristate primitives in the .ucf file. This last item might require you to instantiate primitives if you don't get a nice name you can select uniquely through wildcards. Have fun pushing the rope! - John_HArticle: 130104
austin wrote: > > Some hobby areas I am well aware of use Altera exclusively, others use > Xilinx. It really depends on who used what first. If the first person > used A vs. X, then that entire genre is then using A (as the first > person did all the hard work, and the easiest path is to use what the > person did before you). > I guess I could be considered a "hobbyist" in the sense that I did a few retro-computing designs. See http://mirrow.com/FPGApple However I also consider myself to be a "professional". At least I do EE for a living. The first 3 were done using the S3 Digilent board. The last 2 using the Altera DE1 board. Both A and X tools have advantages. The biggest advantage in the A tools for retro-computing (IMHO) is the ability to edit BRAM (M4K) via JTAG. Built into the tools. Very convenient for loading firmware without needing to rerun the par that takes forever. I got the DE1 board as a quick way to prototype a "real" project. It has single data rate SDRAM that is easier to use. Plus 2 power voltages instead of 3. Why am I telling you all of this? Just to illustrate that choices are often dictated by minor details. So I got a board for real work and decided to make a port of my toy design to get familiar with it. -Alex.Article: 130105
On Mar 14, 3:49 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> wrote: > You haven't stated how long the signal needs to stay nor your > clock frequency. You are right about option 2 needing less > logic, never thought of that, and if you are working in Xilinx > then you may get a nice 16 to one compression in your register > use when the synthesizer packs your registers into an SRL16, > although I'm not sure you can reset all the internal flip-flops. > > The most conventional solution is a counter that counts to your > desired time and triggers. > > Brad Smallridge > AiVision > My clock period is 10 ns, and the delay is 50 ns for now but longer delay is anticipated. IIRC, once I use async reset that automatically prohibits the synthesizer from using SRL16. (Sorry I forgot to mention this is going to a Xilinx Spartan3). I think besides the counter, I need at least two extra FFs to make sure the signal will pass through for the specified time. Thanks.Article: 130106
Antti wrote:
> Spartan-4 (ARM+eth+usb+can) will maybe only announced Q1 2009 with
^^^
Surely s/ARM/PPC/ ? If it has any hard CPU core at all, that is.
I wouldn't bet on it.
Wim Roelandts originally said that Spartan 4 would be out in 2007, so
it seems quite possible that it will be announced in 2008.
Article: 130107"Xilinx User" <anonymous@net.com> writes: > I hope Xilinx introduces Systemverilog synthesis with ISE 10.1 -- competitor > Altera has > been taking the lead for so long now in that area... > (whether anyone actually uses Systemverilog synthesis in a large > FPGA-project, > is a debate for another day...) Well, if it's not obvious that anyone actually uses it, then why should Xilinx make the investment to provide it?Article: 130108
"Xilinx User" <anonymous@net.com> writes: > An little checkbox in the installer-GUI that lets the user override > the installer's platform-autodetect would be really nice : > "install 32-bit tools?" But even that shouldn't be necessary. The install script should notice that the 64-bit tools aren't even present in the WebPACK distribution, and automatically select 32-bit.Article: 130109
"M. Hamed" <mhs000@gmail.com> wrote in message news:86d92fd2-9b27-448f-816a-d1f1c9c3fcaa@i7g2000prf.googlegroups.com... > On Mar 14, 3:49 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> > wrote: >> You haven't stated how long the signal needs to stay nor your >> clock frequency. You are right about option 2 needing less >> logic, never thought of that, and if you are working in Xilinx >> then you may get a nice 16 to one compression in your register >> use when the synthesizer packs your registers into an SRL16, >> although I'm not sure you can reset all the internal flip-flops. >> >> The most conventional solution is a counter that counts to your >> desired time and triggers. >> >> Brad Smallridge >> AiVision >> > > My clock period is 10 ns, and the delay is 50 ns for now but longer > delay is anticipated. > A choice between 5 flops for the shift register and 4 for a counter (3 to count, 1 presumably for the final reset out). It really doesn't matter much does it? Longer delays meaning another flop or two wouldn't do much to sway me one way or the other, longer delays meaning maybe 10 clocks then I probably would go the counter route. Another consideration is whether this input is already synchronized to the clock or not. If not, then you'll need to add synchronizing flops before feeding it into the counter whereas the shift register approach inherently has them (but you would need to lengthen the shift chain to guarantee the 50ns). > IIRC, once I use async reset that automatically prohibits the > synthesizer from using SRL16. (Sorry I forgot to mention this is going > to a Xilinx Spartan3). > Whether you use a sync or an async reset shouldn't matter, if the SRL15 likes sync resets then give it a sync reset. > I think besides the counter, I need at least two extra FFs to make > sure the signal will pass through for the specified time. > Not sure what you mean by this, but I'm guessing it might be having to do with the input maybe being asynchronous to the clock. If that's the case, then you need to synchronize with any approach and take that into account in figuring out if you have your 50 ns or not. Kevin JenningsArticle: 130110
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:13tlvrisdh1a212@corp.supernews.com... > My tristate signals are not being placed > in the IOBs. They are clocked signals, > > Brad Smallridge > AiVision.com > Hi Brad, What John_H said ^. There are limited clock resources to the IOBs. My additional suggestion is to use FPGA editor to visualise the problem. Cheers, Syms.Article: 130111
"Symon" <symon_brewer@hotmail.com> wrote in message news:frf7mi$pkq$1@aioe.org... > "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message > news:13tlvrisdh1a212@corp.supernews.com... >> My tristate signals are not being placed >> in the IOBs. They are clocked signals, >> >> Brad Smallridge >> AiVision.com >> > Hi Brad, > What John_H said ^. There are limited clock resources to the IOBs. My > additional suggestion is to use FPGA editor to visualise the problem. > Cheers, Syms. > Like he said! Whooops!Article: 130112
Can you separate the register from the tri-state? I have always coded this (in Verilog) as input pin; ... reg pin_en; reg pin_out; assign pin = pin_en ? pin_out : 1'bz; Then I assign to pin_en and pin_out however I want, although usually with an always @(posedge clk). The flip-flop will map into the IOB if the resource is available, otherwise into the array.Article: 130113
The simple rule is "use a BUFG." If you have a [very] small fanout, you may be able to get away without it, but you may need to place all your FFs appropriately; otherwise, you have a high probably of lousy clock skew and lousy routing. Ideally, pre-pin-selection planning lets you assign all your potential clocks to appropriate pins; a select number of pins have 'favored' connections to the BUFGs. If you don't have such luxury (and I would guess you don't), you need to carefully control the routing of your input clock to control its phase relative to the input/output data at the IOBs. If you can control the routing (i.e., make the delay predictable), then you can use a DCM to produce a phase-corrected clock (2x, /N, ...), and use normal clock routing resources. (And face the Primary/Secondary restrictions in each quadrant, which gets to be quite a pain when you exceed 8 clocks and want matched BUFGs... but that is another story.) There are lots of good app notes on Xilnx' web site. Enjoy reading. JTW "Daniel" <dteira@gmail.com> wrote in message news:dab9fdbc-46a6-4d02-bd4e-fc8386f2ad77@q78g2000hsh.googlegroups.com... > Hi, > I'm adding new logic to an existing IP. This IP uses a DCM to manage > it's sys_clk. > My logic is using another (external) clock which is an input port to > the top level. > My logic works fine if I don't use DCM nor bufg (a global clock), but > it doesn't pass routing stage. I get this message error: > > ERROR:Place:249 - Automatic clock placement failed. Please attempt to > analyze the Global clocking required for this > design and either lock the clock placement or area locate the logic > driven by the clocks so that that the clocks may > be placed in such a way that all logic driven by them may be > routed. The main restriction on clock placement is that > only one clock output signal for any Primary / Secondary pair of > clocks may enter any region. For further > information see the "Using Global Clock Networks" section in the V- > II User Guide (Chapter 2: Design Considerations) > Phase 5.30 (Checksum:2faf07b) REAL time: 2 mins 11 secs > > Where to start?. I guess the problem are two clocks BUFGMUX#P and > BUFGMUX#S acessing the same quadrant but what to do?. How can I be > sure of what's realy happening?. > > Please help me!!!. > > Thanks, > Daniel. >Article: 130114
6-LUTs? Sounds somthing like ORCA... (ATT -> Lucent -> Lattice) JTW "Kolja Sulimma" <ksulimma@googlemail.com> wrote in message news:a2bcdcfe-1175-4ed3-9004-eb6b47a07a47@13g2000hsb.googlegroups.com... > Until recently comparing 4-LUTs was the way to go. (Except for > pathological cases) > Now Virtex-5 with its 6-LUTs makes life more complicated. > > Kolja > > On 12 Mrz., 04:54, muthu...@gmail.com wrote: >> Hi, >> Some IP vendors gives the complexity of the device in terms of "LCs >> (Logic Cells)". >> How can I calcuate Logic cells from information available in Map >> report? >> >> ********** >> Logic Utilization: >> Number of Slice Flip Flops: 4,288 out of 84,352 5% >> Number of 4 input LUTs: 7,880 out of 84,352 9% >> Logic Distribution: >> Number of occupied Slices: 5,150 out of >> 42,176 12% >> Number of Slices containing only related logic: 5,150 out of >> 5,150 100% >> Number of Slices containing unrelated logic: 0 out of >> 5,150 0% >> *See NOTES below for an explanation of the effects of unrelated >> logic >> Total Number of 4 input LUTs: 8,119 out of 84,352 9% >> Number used as logic: 7,880 >> Number used as a route-thru: 159 >> Number used for Dual Port RAMs: 80 >> (Two LUTs used per Dual Port RAM) >> Number of bonded IOBs: 500 out of 576 86% >> Number of BUFG/BUFGCTRLs: 5 out of 32 15% >> Number used as BUFGs: 5 >> Number used as BUFGCTRLs: 0 >> ************** >> >> Thanks in advance, >> Muthu >Article: 130115
John_H <newsgroup@johnhandwork.com> wrote: >On Mar 14, 10:41=A0am, n...@puntnl.niks (Nico Coesel) wrote: ><snip> >> >> A lot can be said about Altera, but almost every hobbiest FPGA user in >> the world is using Altera devices. This certainly says something about >> the ease of use of Altera parts and software. >> ><snip> > >I'd love to see your reference ;-) Just look around in electronics forums for beginners and start counting. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 130116
austin <austin@xilinx.com> wrote: >Antti, > >Did you actually perform the google search, and read some of the links? > >It is not as crazy as it seems. > >As for "retro computing" I found more Xilinx implementations that any >other (of old computers). > >But, I suggest we drop this, as it really has no meaning. > >Some hobby areas I am well aware of use Altera exclusively, others use >Xilinx. It really depends on who used what first. If the first person >used A vs. X, then that entire genre is then using A (as the first >person did all the hard work, and the easiest path is to use what the >person did before you). > >Regardless, the hobby market is not one that Altera or Xilinx is going >after. And here you guys are making a serious mistake. People tend to continue use the devices they learned work with at home or at school. I see this regulary with interns. If they learned to work with FPGA's from Altera, they will look at Altera first if they need something. So if Altera fits the bill, Altera wins a design-in into a product. I see this happen every time with interns. Ofcourse Altera can be replaced by any manufacturer's name. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 130117
On 15 Mrz., 09:50, n...@puntnl.niks (Nico Coesel) wrote: > austin <aus...@xilinx.com> wrote: > >Antti, > > >Did you actually perform the google search, and read some of the links? > > >It is not as crazy as it seems. > > >As for "retro computing" I found more Xilinx implementations that any > >other (of old computers). > > >But, I suggest we drop this, as it really has no meaning. > > >Some hobby areas I am well aware of use Altera exclusively, others use > >Xilinx. It really depends on who used what first. If the first person > >used A vs. X, then that entire genre is then using A (as the first > >person did all the hard work, and the easiest path is to use what the > >person did before you). > > >Regardless, the hobby market is not one that Altera or Xilinx is going > >after. > > And here you guys are making a serious mistake. People tend to > continue use the devices they learned work with at home or at school. > I see this regulary with interns. If they learned to work with FPGA's > from Altera, they will look at Altera first if they need something. So > if Altera fits the bill, Altera wins a design-in into a product. > > I see this happen every time with interns. Ofcourse Altera can be > replaced by any manufacturer's name. > > -- > Programmeren in Almere? > E-mail naar nico@nctdevpuntnl (punt=.) You are so right. It's sometimes even surprising how much we all "try to play with known toys", I am trying to get rid of my electronics junkyard, so I asked on german forums if someone wants to look and grab things of interest. So one student did come, and all he looked for was PIC stuff, he say he know that, and thats it. No Atmel chip, no FPGA thing, nothing just the things he had used before. I used PIC when PIC15C54 was "hot", as they had almost no competition. I changed to AVR as they are better. But Microchip is still VERY succesful selling his PICs that are really bad architecture, mainly because of their marketing. Every **** student wants PIC, and they will use it in the everyday work later on too. No matter that there are no advantages of using PIC. Its just the routine, and "familiar", it will be used if it fits. So the "educational" and hobby, etc.. is of importance. Also for FPGA vendors i would say. Without the "edu+hobby" popularity of the PIC's Microchip could not have success. 2eurocents AnttiArticle: 130118
Antti <Antti.Lukats@googlemail.com> wrote: > On 15 Mrz., 09:50, n...@puntnl.niks (Nico Coesel) wrote: .. > > And here you guys are making a serious mistake. People tend to > > continue use the devices they learned work with at home or at school. > > I see this regulary with interns. If they learned to work with FPGA's > > from Altera, they will look at Altera first if they need something. So > > if Altera fits the bill, Altera wins a design-in into a product. > > > > I see this happen every time with interns. Ofcourse Altera can be > > replaced by any manufacturer's name. > > > You are so right. It's sometimes even surprising how much we all > "try to play with known toys", I am trying to get rid of my > electronics ... Complex parts like complex FPGA/CPLD need complex toolchain. You have to manage these tools for a long time, if you once decide to roll out some product with this chain. So changing FPGA needs changing the chain and careing for both, so you think double before changing... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 130119
On Mar 14, 10:26=A0pm, ga...@allegro.com (Gavin Scott) wrote: > austin <aus...@xilinx.com> wrote: > Austin's two paragraphs above only make sense together if he believes > that no hobbyist ever turns into (or even communicates with) a > professional FPGA-using engineer. =A0Otherwise half of the game is > getting more mindshare than the competition and having people feel > good about your brand and tools when someday someone says "hey, > maybe we should use an FPGA for this application". > > There's a lot of profit in having your brand be the first one that > people encounter. > Hence the Xilinx University Programme. Certainly, in the UK both Xilinx and Mentor FPGA tools are widely used across Universities. If this isn't promotion to potential professionals then I don't know what is. For the hobbyist, a low-end Digilent board and ISE WebPack never broke the bank. As to implementing DDRx interfaces, having put a DDR2 interface on a V5LX50 device last year, I am not sure that the flexibility of the underlying structure is necessarily worthwhile the hassle for the end user. The general purpose flexibility of the logic is made irrelevant by the number of different pinouts of Xilinx devices in a series. The main gain is for the silicon vendor in being able to have fewer product variants and save real-estate on hard implementations of features that only a few customers want. AndrewArticle: 130120
Brad If you have a similar tristate function on more than one register it may be your synthesiser being clever and removing a "duplicate" register. If reduced like that then when you get to the back end a single tristate register can't be mapped into the I/O and be shared and hence ends up in the fabric. Have a look at the remove duplicate register synthesis options and turn that off and see if that solves your issue. John Adair Enterpoint Ltd. Home of Craignell. The obsolete component solution. On 14 Mar, 22:28, "Brad Smallridge" <bradsmallri...@dslextreme.com> wrote: > My tristate signals are not being placed > in the IOBs. They are clocked signals, > always all on or all off, depending on > reading or writing, and the registration > happens the fabric, not in the IOB. The > data_out signals are registered in the > IOB's correctly. > > I have had this issue before with ISE7.1 > and now again with 9.2. In the Synthesis > properties under Xilinx Specific Options > I changed the defaults Registration > Duplication to check and the Pack I/O > Registers into IOBs to Yes. No effect. > > I really don't want these options anyway. > I really only want the tristate signals > properly placed in the IOBs along with > the data out signals. The defaults should > be OK elsewhere. > > Can anyone help? > > Brad Smallridge > AiVision.comArticle: 130121
Antti wrote:
> yes, Xilinx has purchased many things for slow death.
> in 2004 just before the byout by Xilinx Triscend was about to come to
> the market with the FPGA devices with
> ARM+ethernet+ADC+something i dont remember
The key phrase is *about to*
Most failed startups are responsible for their own deaths
because the marketing geniuses overestimate demand
for the gizmo, then react by changing its
specifications until the money is gone.
A last-minute acquisition at least saves the
jobs of a few engineers. The "almost finished"
product is often a mess.
-- Mike Treseler
Article: 130122Hi, I have a simple question about memory organization. I would like to write a memory controller for IS61LV25616AL SRAM (256K x 16) but I am having trouble understanding how the memory organization works. Datasheet says the memory is organized as 262,144 words by 16 bits which is 256K x 16 but what does that mean in terms of rows and columns ? Is there a memory tutorial that someone can point me to ? or maybe a memory controller that someone has written for an SRAM ? Thanks,Article: 130123
Xilinx User wrote:
> I hope Xilinx introduces Systemverilog synthesis with ISE 10.1
Systemverilog is mainly a simulation upgrade.
-- Mike Treseler
Article: 130124On 15 Mrz., 15:07, Mike Treseler <mike_trese...@comcast.net> wrote: > Antti wrote: > > yes, Xilinx has purchased many things for slow death. > > in 2004 just before the byout by Xilinx Triscend was about to come to > > the market with the FPGA devices with > > ARM+ethernet+ADC+something i dont remember > > The key phrase is *about to* > Most failed startups are responsible for their own deaths > because the marketing geniuses overestimate demand > for the gizmo, then react by changing its > specifications until the money is gone. > A last-minute acquisition at least saves the > jobs of a few engineers. The "almost finished" > product is often a mess. > > -- Mike Treseler sure! it could be they would have died anyway. but now we never know. Antti
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