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
If you use both clock edges, any path between the two clock domains has less than half a clock period available ( since it also must accomodate any duty-cycle difference from 50%.) That's not a smart design decision, if you want to achieve high performance. Peter AlfkeArticle: 100501
Roger,
There is not a way to directly view the GSR signal within a design
but there is a pseudo-way to get it. If you instantiate an FD, and tie
the input to Vcc and connect your clock, the FF will reset to zero when
GSR is asserted and go to one the first clock cycle GSR is deasserted.
You can invert the polarity by setting the INIT attribute to a one and
tying a ground to the input. You may need to place some attributes on
the FF to make sure the tools do not optimize it away thinking it is a
constant but in theory, that should give to a look at to when GSR is
asserted for the rest of your design. I would not know whey you would
every try to build memory within and FPGA out of LUTs configured as nand
and inv gates when you can have much more efficient use of the LUTs when
configured as memories but to each their own.
-- Brian
Roger Bourne wrote:
>
> What I meant by the above was:
> Is there a way to insert the FPGA's GSR net in a shematic design?
>
> The reason I was asking the question was because I was thinking about
> the situation were nand & inv gates are used to constructed a bulky
> (and slow) memory element. (If such a construction is permitted in an
> fpga) . In that situation, the fpga's gsr net would come in handy for
> the memory's element initialization.
>
> -Roger
>
Article: 100502I have a system generator model that utilizes the DDS v4.1 block. I wish to upgrade to the DDS v5.0 block to take advantage of some of the new features. However I have noticed that the interface has changed. My specific application utilizes the phase increment register and a constant phase offset of zero. In my v4.0 design, the accumulator width is set to 32 bits which configures the data input as a 32.32 unsigned integer. The output width is also configurable I use a 16-bit width, which gives a 16.15 signed output and a signal ranging between +/- 1 peak-to-peak. When I try using the v5.0 core with the Frequency set to programmable, it asks for a signed input at the data port. That seems odd because the value should always be positive. The width of this input seems to be set by the frequency resolution. Also I see nowhere where I can set the output resolution or amplitude and the signal is now between +/- 0.5 rather than +/- 1. How can I configure the new core to have the same interfaces as the old ones.? Thanks, -Ira ThorpeArticle: 100503
Brian Philofsky wrote: > Roger, > > There is not a way to directly view the GSR signal within a design > but there is a pseudo-way to get it. If you instantiate an FD, and tie > the input to Vcc and connect your clock, the FF will reset to zero when > GSR is asserted and go to one the first clock cycle GSR is deasserted. > You can invert the polarity by setting the INIT attribute to a one and > tying a ground to the input. You may need to place some attributes on > the FF to make sure the tools do not optimize it away thinking it is a > constant but in theory, that should give to a look at to when GSR is > asserted for the rest of your design. I would not know whey you would > every try to build memory within and FPGA out of LUTs configured as nand > and inv gates when you can have much more efficient use of the LUTs when > configured as memories but to each their own. > I do not actually plan to build memory elements in the FPGA. I only cited as a possible academic situation where one migth require the FPGA's gsr signal. In regard to your proposd idea: Great idea! It needs a clock and as such the oscillator startup time is added to the gsr pulse, but that does not matter. Until the clock shows up, the gsr can be asserted or negated --> gsr being held or released will will have no impact if there is no clock! Thx! -RogerArticle: 100504
John, Actually, the LUT/ROM is replicated twice as much as I said before (18 times 1st stage, 22 times 2nd stage). Synthesis tool was smart enough to reduce size of ROMs memory bits from 35840 bits to 25600 bits (there are few identical values inside every ROM, synthesis tool placed additional decoding logic for input address to reduce memory size). But this is still too much. > You have 20 different addresses for the 20 replications, correct? yes, I have different address for every ROM access, and I need to access all ROMs at the same clock cycle for performance. > Which FPGA family are you using? I want design to be generic, though I ordered Virtex 2Pro board from Digilent so this will be my target. Michal KArticle: 100505
Thanks for all your input. I think it makes most sense for me to have a closer look at PicoBlaze. Is there a good place for PicoBlaze designs apart from the Xilinx PicoBlaze home ? I mean some kind of community like avrfreaks or the piclist ? A place to ask stupid newbie questions, you know ;) P.Article: 100506
"mikel" <mikel262@gmail.com> wrote in message news:1144702316.464096.232020@i40g2000cwc.googlegroups.com... > John, > > Actually, the LUT/ROM is replicated twice as much as I said before (18 > times 1st stage, 22 times 2nd stage). Synthesis tool was smart enough > to reduce size of ROMs memory bits from 35840 bits to 25600 bits (there > are few identical values inside every ROM, synthesis tool placed > additional decoding logic for input address to reduce memory size). But > this is still too much. > >> You have 20 different addresses for the 20 replications, correct? > > yes, I have different address for every ROM access, and I need to > access all ROMs at the same clock cycle for performance. > >> Which FPGA family are you using? > > I want design to be generic, though I ordered Virtex 2Pro board from > Digilent so this will be my target. > > Michal K If you have 40 different 6-bit addresses for 40 different 64x14 ROMs, I don't see how you can do better than 40instances*4LUTs*14bits = 2240 LUTs (or 280 CLBs in your current architecture). Implementing each ROM with fewer than 4 LUTs per bit would be possible for some 6-in-1 out functions. Each ALM in the Stratix-II series (roughly equivalent but twice the LUT size as a Xilinx slice) can provide a 64x1 ROM. You could use a BlockRAM to provide 2 ports of 14 bits each (up to 36 bits available) to displace 56 LUTs each. The 4.5 kbit Altera M4K blocks would be more "efficent" since only 64 entries are needed in your application and there are typically many more M4K blocks than BlockRAMs in equivalent A vs X devices. It's quite possible you could time-multiplex your 14-bit lookups at 2x, 3x, even 4x your main design speed since the ROM lookup time as implemented in distributed CLB SelectRAM is one LUT plus MUXF5 plus MUXF6, roughly less than 2 levels of logic in a pipelined implementation. The bottom line is that you have to pull out 40 unique 14-bit values. If there is no convenient way to reduce the uniqueness, the replication has to be there. What does help is that each LUT or LE can give you 16 bits of ROM. Each ALM can give you 64 bits of ROM.Article: 100507
Peter Winkler wrote: > Thanks for all your input. > > I think it makes most sense for me to have a closer look > at PicoBlaze. > > Is there a good place for PicoBlaze designs apart from the > Xilinx PicoBlaze home ? I mean some kind of community like > avrfreaks or the piclist ? A place to ask stupid newbie > questions, you know ;) You should also look at the extended variant : http://bleyer.org/pacoblaze/ plus rhere are good links on this page. -jgArticle: 100508
All- I am combining 2 .bit files into one .mcs for an XCF16P (XC3S1500-676 and XC3S1000-456). In both cases I've set the Configuration Rate parameterto 50. It takes 200 msec for DONE to go high -- that sounds too slow. Can this be right? Which .bit file takes precedence? Is there something additional that needs to be set? -JeffArticle: 100509
In article <1144487259.825320.212420@i40g2000cwc.googlegroups.com>, burn.sir@gmail.com wrote: > Having seen way too much spam on this newsgroup lately, I have come > with a possible solution that just might work. > > Add a section to FPGA FAQ where the known names on the newsgroup will > list the companies they recommend (plus some explanation). Next time > someone spams the list about "high quality PCB", or what the hell it > is, we post a polite response saying that no one should support spammer > companies and we suggest you choose another manufacture from the list > below (link to FPGA-FAQ follows).Given that spammers only care about > money, seeing they are loosing customers might stop them from spamming > the list. > > This way, you will also support the local companies that you think are > doing a good job ;) > > > We could also add another section about newsgroup netiquette, 3leet > English and what we think about doing other peoples homework. This is > of course not as big problem as spammer, but it is still a little bit > annoying sometimes. > > > Furthermore, someone should contact Google, notifying them about the > existence of a group FAQ. I think the biggest problem with the FAQ is > that the ones that dont know about it are the ones that really need to > read it :) > > > regards > - Bruns Considering they dont read responses, and often its via a 'bot' anyway, i dont think it will help.. Though supporting good companies is always a good thing to do.Article: 100510
Jeff Brower wrote: > I am combining 2 .bit files into one .mcs for an XCF16P (XC3S1500-676 > and XC3S1000-456). In both cases I've set the Configuration Rate > parameterto 50. It takes 200 msec for DONE to go high -- that sounds > too slow. XCS1500 config is 5,214,784 bits XCS1000 config is 3,223,488 bits ( 5214784+3223488 bits ) / 50 MHz = 169ms (as a lower bound) How much faster do you expect it to be? Alan NishiokaArticle: 100511
I'm trying to use the TFT IP core provided by Xilinx and am unable to simulate the entire system using ModelSim 6.1e. I've compiled the EDK and ISE libraries correctly, and I'm simply trying to find a way to let my verilog files know where to find the necessary files. When compiling the TFT piece, I receive the following error messages: # ** Error: (vsim-3033) C:/vga_dcr_ddr/pcores/plb_tft_cntlr_ref_v1_00_d/hdl/verilog/plb_tft_cntlr_ref.v(501): Instantiation of 'BUFG' failed. The design unit was not found. # Region: /system/vga_framebuffer/vga_framebuffer/BUFG_pixclk # Searched libraries: # plb_tft_cntlr_ref_v1_00_d # ** Error: (vsim-3033) C:/vga_dcr_ddr/pcores/plb_tft_cntlr_ref_v1_00_d/hdl/verilog/plb_tft_cntlr_ref.v(526): Instantiation of 'DCM' failed. The design unit was not found. # Region: /system/vga_framebuffer/vga_framebuffer/DCM_pixclk # Searched libraries: # plb_tft_cntlr_ref_v1_00_d The only thing I can think to do would be to copy the BUFG and DCM components from the ISE library into the simulation directory so that the compiler can find them. But, in order to do that, I think I need to modify the _info file that sits in the root directory to indicate that those files are there. Are there any other steps that I'm missing?Article: 100512
Alan- Thanks for your reply. > XCS1500 config is 5,214,784 bits > XCS1000 config is 3,223,488 bits > > ( 5214784+3223488 bits ) / 50 MHz = 169ms (as a lower bound) > > How much faster do you expect it to be? The first FPGA has a PCI core. We were hoping to boot under 100 msec. Is there a way to go faster than 50 MHz without resorting to external clock + INIT gating circuitry? -JeffArticle: 100513
hi i am working on mp3 decoder in vhdl. i need to read the bitstream and decode it. the bitstream is in a file so i used the commands for file reading. but i found that quartus doesn't support the read, readin, write, writein commands, i.e textio is not supported. what should i do now to read that bitstream..plz suggest. regards shikhaArticle: 100514
Are you including the unisims directory in the verilog simulation with a -y option? You need to tell Verilog where the models for the BUFG and the DCM live. John ProvidenzaArticle: 100515
Jeff Brower wrote: > The first FPGA has a PCI core. We were hoping to boot under 100 msec. > Is there a way to go faster than 50 MHz without resorting to external > clock + INIT gating circuitry? I don't know. This is one of the reasons I have always used external pci bridges. But I thought there was more time during pci config. All I can think of is using two config proms or using parallel config mode. Alan NishiokaArticle: 100516
I'm assuming by that I need to put the -y option in the system.do file that gets generated by the EDK... If so, I'll try it and see what I can come up with. Thanks.Article: 100517
Alan Nishioka wrote: > Jeff Brower wrote: > >>The first FPGA has a PCI core. We were hoping to boot under 100 msec. >>Is there a way to go faster than 50 MHz without resorting to external >>clock + INIT gating circuitry? > > > I don't know. This is one of the reasons I have always used external > pci bridges. But I thought there was more time during pci config. > > All I can think of is using two config proms or using parallel config > mode. On that line, what about one of the 150Mbit Winbond SPI memories, and a small CPLD to turn it into parallel-config ? -jgArticle: 100518
Jim Granville wrote: > Alan Nishioka wrote: > >> Jeff Brower wrote: >> >>> The first FPGA has a PCI core. We were hoping to boot under 100 msec. >>> Is there a way to go faster than 50 MHz without resorting to external >>> clock + INIT gating circuitry? >> >> >> >> I don't know. This is one of the reasons I have always used external >> pci bridges. But I thought there was more time during pci config. >> >> All I can think of is using two config proms or using parallel config >> mode. > > > On that line, what about one of the 150Mbit Winbond SPI memories, and oops, that should be 150Mbd, of course....Article: 100519
We are using a Lattice LC4256V CPLD for a new design and we're having some problems with open drain outputs + 5V pullups. We've debuged and removed items from the system to the point where we have the single CPLD (pins configured 3.3v CMOS open drain) connected to a 4.7K resistor to +5V. We configured the pins to output a 4MHz square wave for testing. When we hook a scope up to the pins, we see that the voltage rises at a very slow rate at the high edge of the clock pulse and only makes it to about 2V before the falling edge takes the output low. When we remove the pullups and set the pins to normal 3.3V mode we get a clean square wave, it is only when using pullups that problems are created. Any ideas on why the pullup is taking so long to bring the pin voltage to 5V? We have used 4.7K pullups with other FPGA / CPLD designs before in designs faster than 4 MHz without any problems. Doing the math, it seems the acting capacitence from the CPLD is something like 15uF to have the pullup rise so slowly. Am I doing something wrong here?Article: 100520
shawnn@gmail.com wrote: > We are using a Lattice LC4256V CPLD for a new design and we're having > some problems with open drain outputs + 5V pullups. We've debuged and > removed items from the system to the point where we have the single > CPLD (pins configured 3.3v CMOS open drain) connected to a 4.7K > resistor to +5V. > > We configured the pins to output a 4MHz square wave for testing. When > we hook a scope up to the pins, we see that the voltage rises at a very > slow rate at the high edge of the clock pulse and only makes it to > about 2V before the falling edge takes the output low. When we remove > the pullups and set the pins to normal 3.3V mode we get a clean square > wave, it is only when using pullups that problems are created. > > Any ideas on why the pullup is taking so long to bring the pin voltage > to 5V? We have used 4.7K pullups with other FPGA / CPLD designs before > in designs faster than 4 MHz without any problems. Doing the math, it > seems the acting capacitence from the CPLD is something like 15uF to > have the pullup rise so slowly. Am I doing something wrong here? The maths is suspect if you get 15uF. 4MHz is 125ns H/L, and a 125 ns Tau, is 26pF/4K7 So, your symptoms indicate ~26pf system c : That is highish, but not outlandish. What else is this connected to : Loads, track etc ? Simple solution is to lower the pullup... -jgArticle: 100521
Thank you peter, but do you have any idea about the block ram issue? That is more important to me right now. NimayArticle: 100522
John_H wrote: > "Fizzy" <fpgalearner@gmail.com> wrote in message > news:1144690848.814144.204880@t31g2000cwb.googlegroups.com... > ... >> Why do we need >> clock on FPGA when our design does not have any clock input[?] John is right of course, but to make it perfectly clear: if you have no clocked logic, that is, all your output are combinatorial functions of the input, then you don't need to provide a clock to your FPGA at all and the design will still work as expected. However, using an FPGA in such a situation would be wasting most of the expensive machinery that is an FPGA. Maybe you only really need a CPLD. TommyArticle: 100523
Hi, Im somewhat new to the ISE and was wondering if there was a way to give the Xilinx tool an area constraint ( say in number of LUT's used) for a given VHDL implementation? For instance, I have created a module that I want to restrict to 500 LUT's if possible, because I will be having other modules that will need the pending space. Im not exactly sure how I would go about this using the PACE tool, and any help would be appreciated. I am sure there is a trivial way to do it, but I seem to be overlooking it at the momentArticle: 100524
Alan- > I don't know. This is one of the reasons I have always used external > pci bridges. But I thought there was more time during pci config. I looked up the PCI 2.3 spec, time to first config access is 2^25 clocks, or about 250 msec at 133 MHz. We have customers though who prize fast turn-on time, so I'm always looking to get under that 100 msec mark. > All I can think of is using two config proms or using parallel config > mode. 2 config proms? I wish. The board is jammed -- 16 layers, blind vias, lots of things like 201s and 2x3 mm oscillators. Pic of the board is here: http://www.signalogic.com/sigc5561_ptmc.htm Parallel config maybe... need to think about that. -Jeff
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