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
There is a very simple, albeit wasteful solution: Just cascade two flip-flops. The first one clocked on the falling edge,(usually indicated by a bubble on the clock input), its Q driving a second flip-flop's D, and this second flip-flop is clocked by a rising-edge clock This contraption accepts data right before the falling edge, and outputs the data right after the subsequent rising edge. And the output stays stable until the next rising edge. Ideal behavior. It uses a total of four latches, and runs only at half the conventional clock rate, but it uses conventional circuit elements. Efficiency be damned! Peter AlfkeArticle: 101176
so wonderful site !!!!!!Article: 101177
Has anyone implemented OR1K on a XUP?Article: 101178
Rene Tschaggelar skrev: > At least Analog Devices and also Fairchild propose > analog switches as level translators to interface > eg 1.8V logic to 3.3V logic. I fail to recognize > how this is going to work. The Low state is > understood, it is just pulled down, but how > is a 1.8V output high propagated to a 3.3V > high by just a resistor ? > > Apart from the analog switches, what alternative > are there to interface an 1.8V FPGA to normal 3.3V > or 5V logic ? Yes, switchable bidirectional, or > auto bidirectional is preferred. > Else what unidirectional solutions are there ? > > Rene something like this? http://www.fairchildsemi.com/ds/74/74VCX164245.pdf -LasseArticle: 101179
langwadt@ieee.org wrote: > Rene Tschaggelar skrev: > > >>At least Analog Devices and also Fairchild propose >>analog switches as level translators to interface >>eg 1.8V logic to 3.3V logic. I fail to recognize >>how this is going to work. The Low state is >>understood, it is just pulled down, but how >>is a 1.8V output high propagated to a 3.3V >>high by just a resistor ? >> >>Apart from the analog switches, what alternative >>are there to interface an 1.8V FPGA to normal 3.3V >>or 5V logic ? Yes, switchable bidirectional, or >>auto bidirectional is preferred. >>Else what unidirectional solutions are there ? >> >>Rene > > > something like this? http://www.fairchildsemi.com/ds/74/74VCX164245.pdf > > -Lasse and TI and Philips also have expanding families of dual-Vcc translators. Dual Vcc works much better at low-power than the limiting resistor kludges ( tho with FPGA icc's that probably gets lost ) Also, there are Low power CPLDs like the XC2C32A Coolrunner, and Atmel ATF1502BE that have Dual VccIO, so can also do 'smarter' level shifting tasks. -jgArticle: 101180
Francesco wrote: > Hi all, > On www.poderico.co.uk you can download the free C compiler for > Picoblaze version 1.7.7 > In the next 2 months the optimizer should be ready and the code > generated will be shorter. > I' wish to design the debugger too. > Any help and suggestions is welcome. Looks impressive. Have you also looked at the quite similar ( but open sourced ) Lattice Mico8, http://www.latticesemi.com/products/intellectualproperty/referencedesigns/8bitmicrocontrollermico8.cfm and also the PacoBlaze ? http://bleyer.org/pacoblaze/ In the examples section, you could add the output files, with the source, so users can easily see the code generated ? -jgArticle: 101181
simon.stockton@baesystems.com wrote:
> ... I want to clock data into an entity on the falling edge of a
> clock and clock data out of an entity on the rising edge of the same
> clock.
I don't know about VHDL, butt something like this in Verilog would
probably do the trick:
module xyz(in, out)
input in;
output out;
reg temp;
always @(negedge clock)
temp<= in; // could be combinatorial logic here also
always @(posedge clock)
out<= temp; // could be combinatorial logic here also
endmodule
Article: 101182I have a mismatch in Modelsim behavioral simulations using 1) VHDL testbench in ISE and 2) manual entry of stimuli. While the vector inputs are same in time and values in both cases, the output, however, is different. The manual simulation seems working as designed but the testbench based simulation has a delayed output and the current state of FSM is stuck to certain state. This is the first time I have encountered this problem, otherwise I have been consistently getting same results whether I manually simulate the design or use a testbench. I am quite clueless here. I don't know whether the problem is attributed to the Modelsim or the design itself since Modelsim gives two different results on same source file, the mode of simulation is different though. Regards, YZArticle: 101183
Just a reminder: Downhole oil exploration has used Xilinx FPGAs since many, many years ago, running them for weeks on end at 175 degrees C at the bottom of a borehole 200 degr C proved to be problematic. These chips were not in plastic packages, but usually assembled as die in a ceramic hybrid. Of course, we guaranteed no parameters, but functionality did not suffer. (My contacts were always either from Texas, or Paris, or Norway, the three hotbeds of oil exploration) Peter AlfkeArticle: 101184
hey Yaseen; i dont think so. modelsim and ur testbench should produce same results. modelsim is basically the simulation tool. check at the clock, input values, control signals and since you have to force values in modelsim, check out if u doing it correctly. the timing is the same. Cheers AbbsArticle: 101185
Peter Alfke wrote: > Just a reminder: > Downhole oil exploration has used Xilinx FPGAs since many, many years > ago, running them for weeks on end at 175 degrees C at the bottom of a > borehole > 200 degr C proved to be problematic. Any ideas what failed / why ? I thought the lifetimes degraded in a simple log scheme, with temperature, and that 200'C would work, but for less time. 'Disposable' probes is really the mindset needed in this market sector ... -jgArticle: 101186
I think it was not a life-time issue, but rather a parametric change that prevented operation. But I do not really know. Most of the oil-drillers where happy and appreciative that they had any configurable logic that worked at all (they also used Z80s and some SRAMs plus some A/Ds.) Brave souls and nice guys... Peter AlfkeArticle: 101187
Hi Folks, I had published some info about Altera USB Blaster protocol about a year ago (march 2005) http://wiki.openchip.org/index.php/Altera_USB_Blaster but I did not finish the project of making USB Blaster clone - there are since that 2 different companies offering USB Blaster either as standalone or as add-on function on FPGA board, but now there is also a working solution published under GPL license available from http://www.ixo.de/info/usb_jtag/ there are 2 flavors one uses FT245 + 64 macrocell PLD the other option emulates the FT245 and PLD with general purpose USB microcontroller. In the download archive is firmware for Cypress FX2 but its relativly easy to port to other USB MCU as well. As example it would fit into 4k code limit of the KEIL compiler supplied with SiLabs USB MCU's C8051F326 as example is very low cost USB MCU (2.36USD qty 1 !) - I have not fully ported it to SiLabs but initial testing is ok AnttiArticle: 101188
sorry the title was wrong - its USB Blaster, not Byteblaster of course AnttiArticle: 101189
Yes, binary only for windows!Article: 101190
>Have you also looked at the quite similar ( but open sourced ) >Lattice Mico8, Yes I had a look at Lattice Mico8, but to be honest at work I use only Xilinx... >and also the PacoBlaze ? I think Pacoblaze is compatible with picoblaze, so you can use the compiler with pacoblaze in any FPGA. >In the examples section, you could add the output files, >with the source, so users can easily see the code generated ? OK I will do. Does anybody know how to read/write the BRAM using the JTAG? I need this to design the debugger.... Thanks all you. FrancescoArticle: 101191
bjzhangwn schrieb: > When I test my udma33 interface , I write the first sectors with LBA > address mode,but the datas I read from the same address are diffrent > from which I write in. I would test things in this order: PIO identify device ... useful data? PIO write ... PIO read ... same data? PIO write ... UDMA read ... same data? UDMA write ... PIO read ... same data? UDMA write ... UDMA read ... same data? looks like you started with the most complicated combination ... bye, MichaelArticle: 101192
Jim Granville wrote: > Peter Alfke wrote: >> Just a reminder: >> Downhole oil exploration has used Xilinx FPGAs since many, many years >> ago, running them for weeks on end at 175 degrees C at the bottom of a >> borehole >> 200 degr C proved to be problematic. > > Any ideas what failed / why ? > I thought the lifetimes degraded in a simple log scheme, with > temperature, and that 200'C would work, but for less time. > 'Disposable' probes is really the mindset needed in this > market sector ... > > -jg > Disposable probes (and other electronics) are common in the oil industry. High temperatures are a problem, but it's actually often temperature changes that are the worst - tolerating repeated temperature changes from room temperature to 125 C can be worse than sustained higher temperatures. The other big problem is vibration - cards get shaken to pieces. So you often get systems specified for, say, 20 hours total run time - after which it is replaced *before* it breaks.Article: 101193
Hello, We have a design with master PCI DMA in 64 bits. This design implements the xilinx PCI 64/32 bits IP. The problem is that our board should be plugged in various versions of the PCI bus ( 64 bits/ 66 Mhz and 32 bits/ 33 mhz, 32 bits / 66 Mhz ). My question is : Is the IP abble to transparently handle the fact that the board is plugged in a 32 or 64 bit PCI slot ? The goal is to have only one design that feeds the PCI master DMA section with 64 bits data whether the bus is 32 or 64 bits wide. What are the limitations with this IP ? Are there specifics configuration or design stuffs to add ? Thanks for your feedbacks. Stéphane.Article: 101194
The DBC1C12 board is metion in this post is avalible at Elfa in Sweden, not super cheep but afordable. Regards FredrikArticle: 101195
Hi Charles,
<charles.eddleston@gmail.com> wrote in message
news:1145991307.363533.313660@g10g2000cwb.googlegroups.com...
> Ben-
> Thanks for the suggestion - my explaination wasn't very clear: Our
> first iteration used a small BRAM on the PLB bus to boot, loaded SDRAM
> (which was defined as cached memory space), and then ran out of SDRAM.
> With the all the PLB arbitration and overhead logic, this resulted in a
> 4% of our virtex 4 (fx20). Currently, we're around 85% and would like
> to save this 4% to help build time and allow for future flexibility.
Thanks for the clarification. This is quite puzzling!
Are you using any of the memory protection features of the PowerPC, or is
this all running in a flat memory space in supervisor mode? Just to rule out
any odd effects due to TLB etc.
What are you using to debug the bootloader (GDB/source level, or raw XMD)?
Is the bootloader written in ASM or C? Where is the application code that is
written to SDRAM coming from (flash, I guess)? Does your bootloader verify
that the code has been transfered succesfully?
> if I step the processor, it gets lost and never returns.
If in XMD you then do a "stop", what happens? Do you get a "processor
stopped at 0xwha73v3r", or something like "target cannot perform the
operation"? Where do your interrupt vectors live (if in fact you have any)?
> the first instruction out of SDRAM is completed and then PPC405 stops
So your "bctrl" does the Right Thing (sets PC from CTR [which ==0x2000] and
stores PC+4 in LR), and then the "mr r6, r5" happens OK, and then the whole
thing goes up the creek, right? It sounds for all the world like it's taking
some interrupt vector into the middle of nowhere.
Sorry for the deluge of questions - you don't have to answer them all! I'm
just trying to get a feel for what your system looks like.
Cheers,
-Ben-
Article: 101196Thanks,But the design don't have a cpu,the test must be all in FPGA,so the tests are difficult,if I do this ,then the state machine will be very complicate,The only way I can do are to test it under the UDMA mode!Article: 101197
Ray Andraka wrote: > Roger Bourne wrote: > > Hello all, > > > > I am attempting to expand the 18x18 multipliers as provided in the > > xilinx Spartan 3 series. > > I followed the proposed implemention of expanding the multipliers as > > described in the xapp467.pdf app note (figure 5). However, I arrived at > > an impasse: > > When the operand is splitted up in 2 or more partial operands of 18 > > bits, the sign-extension of the operand does not carry over -I'll > > expalin: > > E.g Lets say we want to multiply (-1)in18bitsx(1)in 22bits.The 22 bit > > operand is splitted in 2 4-bit(lsb) and 18-bit(msb) operands. Thus, > > when we multiply the lsb part: 3FFFFh(=-1)x1h=3FFFFFh(=-1), we obtain a > > non-nil answer. However, when we multiply the msb part: > > 3FFFFh(=-1)x00000h=000000000h, we obtain a nil answer. When the 2 > > partial products are added and the bits properly weighed as to > > constructed the final product, the msb bit(sign bit) will be 0. > > Consequently, resulting in a positive product when a negative one was > > expected (-1 was expected, FFFFFFFFFFh.) > > > > I feel I must be doing something wrong.. > > Please advise > > -Roger > > > > > The lower parts of the inputs have to be treated as unsigned, and you > need to form partial products of all the peices: > > A = AH*2^n + AL > B = BH*2^m + BL > > A*B = AH*BH*2^(m+n) + AH*BL*2^n + AL*BH*2^m + AL*BL > > AL and BL are unsigned, AH and BH are signed if A and B are signed. > > In your case, I guess you have only one of the operands split so: > A*B = AH*B*2^n + AL*B, AL is unsigned, AH and B are signed. > > Your example has AH=0, AL=1, n=4, B=-1 > A*B = 0 + -1 = -1. Keep in mind your partial products require sign > extension to the full width of the full product in order to add them > together. Sign extending the lower partial products fixed the problem. Now, the products obtained make sense. ThanksArticle: 101198
Hello all, I always wondered the following: How are constants implemented in an FPGA ? How many can be stored without causing bottlenecks (routing issues)? A quick scan of a Spartan3 indicated there is no ROM. Thx -RogerArticle: 101199
Roger Bourne wrote:
> How are constants implemented in an FPGA ?
All FPGA gates are synthesized in look-up tables.
A constant is synthesized with tables set for fixed output.
Think of it as wires to power or ground.
> How many can be stored
> without causing bottlenecks (routing issues)?
Try it and see.
One constant bit per LUT is maximum.
-- Mike Treseler
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