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
Could anyone tell me,how much time cardbus reset CRST# signal will be asserted after power signal becomes good.Article: 103326
jpvarkey@gmail.com schrieb: > Could anyone tell me,how much time cardbus reset CRST# signal will be > asserted after power signal becomes good. NO this time is vendor dependant AnttiArticle: 103327
Antti wrote: > jpvarkey@gmail.com schrieb: > > > Could anyone tell me,how much time cardbus reset CRST# signal will be > > asserted after power signal becomes good. > > NO > > this time is vendor dependant > > Antti Could you tell me what is the time according to cardbus specification, that CRST# must be asserted.Article: 103328
"Zara" <yozara@terra.es> wrote in message news:kidq7255c982a7he0fu8f1tt3p8vtpbsj2@4ax.com... > On Wed, 31 May 2006 09:04:57 +0800, "Mr. Ken" <Mr. Ken@asdf> wrote: > > >My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the > >best precision possible. Without considering clipping and range issues, I > >am using multiplication by 59/16, which gives 0.599% error. What better > >approach can I use? > > > >I am going to implement the calculation in ASIC, thus less complexity is > >what I am expecting. > > > > 5316/1433 > Error=0.0001133% That's too much resource I guess. John_H's 115/31 offers very good precision, only if I can make a /31 as small as possible.Article: 103329
Hi Joey,
"Joseph" <joeylrios@gmail.com> wrote in message
news:1149033371.430502.37250@i40g2000cwc.googlegroups.com...
> I have a piece of IP that acts as a slave on the PLB. I would like
> writes to this IP to be 64bits, while reads from it are OK at 32bits.
> The sample driver that was generated by the IP wizard gives functions
> for reads/writes or 32 bits as expected (by mapping them to
> XIo_In/Out32). Do I need to do writes in two transfers? If not, how
> do I write 64bits?
The fundamental limitation here is that the PowerPC-405 is a 32-bit core. So
there are no instructions to load/store 64 bits of data at a time as an
atomic unit. So from the processor core's perspective, you have to do two
32-bit stores. (The XIo_In and XIo_Out functions are basically just a
wrapper around load/store instructions, but with an added "eieio" to make
sure the operations don't get re-ordered by the hardware.)
As you say, the PLB is in fact capable of doing multi-word transfers, and is
wide enough to do 64-bit transfers in a single data beat. However, aside
from enabling this functionality in the first place, the processor has no
control over whether this actually occurs.
Without having done any experiments, my gut feeling is that using two calls
to XIo_Out() back to back will not result in a 64-bit transfer, because of
these "eieio"s. Your best bet is probably to try something like:
typedef unsigned long long bits64;
volatile bits64 *my_reg = (volatile bits64 *)(REG_ADDRESS);
*my_reg = some_value;
...and then watch the bus and see what happens.
Hope that helps, or least makes sense... :)
-Ben-
Article: 103330Mr. Ken schrieb: >>>My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the >>>best precision possible. Without considering clipping and range issues, I But I guess this is a starting point. How wide will the result be? Minimum is 11 bits. Having a precision greatert than 1/2^10 ~ 0.001 is useless. A signed 16 Bit bit result need no more then 1/2^15 ~ 0.00003 >>>am using multiplication by 59/16, which gives 0.599% error. What better >>>approach can I use? Hmm. Nice approach. But why not investigating further? Y = X * M / D D M error 16 59,3552 59 0,0059843114 32 118,7104 119 -0,0024395504 64 237,4208 237 0,0017723805 almost 11 bit signed 128 474,8416 475 -0,0003335849 256 949,6832 950 -0,0003335849 512 1899,3664 1899 0,0001929064 1024 3798,7328 3799 -0,0000703392 2048 7597,4656 7597 0,0000612836 almost 16 bit signed 4096 15194,9312 15195 -0,0000045278 So choose the precision you want. >>>I am going to implement the calculation in ASIC, thus less complexity is >>>what I am expecting. The division is free when using powers of two. So all you need is a 6..14 bit multiplier. Regards FalkArticle: 103331
Hey there, I'm trying to simulate a design generated with EDK 7.1 that uses the plb_gemac core (version 1.01.a). When I try and load the design into Modelsim SE (using generate simulation hdl files, then export to proj nav, and using a testbench added to the proj nav project), the loading fails on the plb_gemac part, claiming there is "no default binding for component at u0". A full output of the model sim warning can be seen below. I've tried generating a new EDK project with just a plb_gemac in addition to the usual ppc/bram/plb/uart bits, and I get the same error. Any suggestions as to where I might be going wrong? -- Michael # Loading C:/Xilinx/libs/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/plb_gemac_v1_01_a/.reclock_align(structural) # Loading C:/Xilinx/libs/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.fd(fd_v) # Loading C:/Xilinx/libs/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/plb_gemac_v1_01_a/.cntr14bit8(imp) ... etc C:/Xilinx/libs/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.fddrrse(fddrrse_v) # Loading work.dcm_module_0_wrapper(structure) # Error loading design # Error: Error loading design # Pausing macro execution # MACRO C:\SWIFT\gemac_sim_test\projnav\projnav.do PAUSED at line 4Article: 103332
<jpvarkey@gmail.com> wrote in message news:1149063863.903400.230380@j55g2000cwa.googlegroups.com... > Could you tell me what is the time according to cardbus specification, > that CRST# must be asserted. Do you not think it's about time you got hold of the relevent specs for what you're trying to build? Nial.Article: 103333
Nial Stewart schrieb: > <jpvarkey@gmail.com> wrote in message news:1149063863.903400.230380@j55g2000cwa.googlegroups.com... > > > > Could you tell me what is the time according to cardbus specification, > > that CRST# must be asserted. > > > Do you not think it's about time you got hold of the relevent > specs for what you're trying to build? > > > Nial. good point, but the time after power supply ramps up and the system asserts CRST first time is not in the specs and can not be as it depends on the host system. and very likely the CRST may occour several times during boot (similarly as PCI RESET does) so there is no answer. the OP wants to know if the slow FPGA configuration time is ok, ie if the FPGA has time to configure before CRST, but there is no way of telling that time. To be on safe side one should assume that CRST could come as early as say 20ms after power good. I dont see any restriction for such short delay. In real systems it is more likely longer, but no specs on minimum time. AnttiArticle: 103334
Antti wrote: > Nial Stewart schrieb: > > > <jpvarkey@gmail.com> wrote in message news:1149063863.903400.230380@j55g2000cwa.googlegroups.com... > > > > > > > Could you tell me what is the time according to cardbus specification, > > > that CRST# must be asserted. > > > > > > Do you not think it's about time you got hold of the relevent > > specs for what you're trying to build? > > > > > > Nial. > > good point, but the time after power supply ramps up and the system > asserts CRST first time is not in the specs and can not be as it > depends on the host system. and very likely the CRST may occour several > times during boot (similarly as PCI RESET does) so there is no answer. > > the OP wants to know if the slow FPGA configuration time is ok, ie if > the FPGA has time to configure before CRST, but there is no way of > telling that time. To be on safe side one should assume that CRST could > come as early as say 20ms after power good. I dont see any restriction > for such short delay. In real systems it is more likely longer, but no > specs on minimum time. > > Antti So does that mean CRST# could be asserted atleast 20ms , which gives enough time for FPGA to get configured?Article: 103335
jpvarkey@gmail.com schrieb: > Antti wrote: > > Nial Stewart schrieb: > > > > > <jpvarkey@gmail.com> wrote in message news:1149063863.903400.230380@j55g2000cwa.googlegroups.com... > > > > > > > > > > Could you tell me what is the time according to cardbus specification, > > > > that CRST# must be asserted. > > > > > > > > > Do you not think it's about time you got hold of the relevent > > > specs for what you're trying to build? > > > > > > > > > Nial. > > > > good point, but the time after power supply ramps up and the system > > asserts CRST first time is not in the specs and can not be as it > > depends on the host system. and very likely the CRST may occour several > > times during boot (similarly as PCI RESET does) so there is no answer. > > > > the OP wants to know if the slow FPGA configuration time is ok, ie if > > the FPGA has time to configure before CRST, but there is no way of > > telling that time. To be on safe side one should assume that CRST could > > come as early as say 20ms after power good. I dont see any restriction > > for such short delay. In real systems it is more likely longer, but no > > specs on minimum time. > > > > Antti > > > So does that mean CRST# could be asserted atleast 20ms , which gives > enough time for FPGA to get configured? means nothing. the time after power good to first time CRST asserted can be from 20ms (or maybe less) to 20,000 years. short you can not count that FPGA can configure before CRST asserted, depends on the config method and bitstream size etc AnttiArticle: 103336
mike_la_jolla wrote: > We had the top pop off of a VirtexII-Pro 2vp70 (1704BGA) and need to > reattach it. The board and FPGA work fine. For some reason, Xilinx is > refusing to tell us how to reattach the top correctly. Help please. > What is the proper type of glue and the procedure? Some of the assembly epoxies are listed here: http://www.xilinx.com/bvdocs/notifications/xcn05011.pdf And a side view of the heatspreader package assembly is here, along with cautions about applying shear forces to the lid: http://www.xilinx.com/bvdocs/appnotes/xapp426.pdf If this is just a lab board you want to keep running, Bob's advice sounds fine to me, but I wouldn't ship anything with a reworked lid. If you're drawing lots of power, note that the re-epoxied heatspreader may not work as well as the original. Another possibility (if low power) would just be to glop a suitable encapsulant over the exposed die to protect it. BrianArticle: 103337
I'm planning on using the TXPOLARITY and RXPOLARITY attributes in the RIOs on a Virtex-II Pro device (via Aurora cores) to swap the function of the N and P lines in order to help improve the path of PCB tracks to an edge connector. Has anyone used this polarity swapping capability before? Does it work OK? Are there any "undocumented features" or pitfalls that I should know about before designing the board in this way? TIA, Rog.Article: 103338
Anyone have info on what fpga/cpld costed at different points in time and their capacity ..?Article: 103339
I'm having trouble configuring a Spartan 3 in parallel slave mode. The mode pins are set with M0 tied to GND and M1,M2 left pulled up internally to 2.5 volts. I verified these voltages with a meter. I am driving PROG_B low for a few microsecs then high. The DONE and INIT_B signals go low and INIT_B goes high again. I set RDWR_B low and start clocking data in by setting CS_B low and using the WR_N signal from the DSP to clock CCLK on the trailing edge. I have looked at all of these signals with the scope and they look clean and have good timing. But no matter how much data we clock into the Spartan 3, we never see either INIT_B go low or DONE go high. DONE has a 10 kohm pullup resistor to 2.5 volts and a buffer converts this signal to 3.3 volts for the DSP. I do see something odd on the BUSY pin. It goes high for some 800 ns. The data sheet says I don't even have to monitor this pin if I keep the CCLK rate below 50 MHz. We are clocking data into the part at less than 10 MHz. Any idea what could be wrong?Article: 103340
c d saunter wrote: > Aurelian Lazarut (aurash@xilinx.com) wrote: > : Hi Gabor, > : why a non-locked pin should be considered an error? The reason a non-LOCed pin is an error on a board that has already been placed routed and assembled, is that the tools will take this I/O and assign it to any available I/O pin of the FPGA. This can be very bad depending on the net connected to the essentially randomly selected pin. Also sometimes non-LOCed IOB's represent signals that were unintentionally assigned an I/O buffer. Obviously I can constrain a pin to a location. Sometimes I mis-spell a pin name in a design (vs. a standard .ucf for the board). In a design with for example an XC2V1000 with 300 or more used IOB's, it is easy to mess one up. Another problem is when using bused I/O and the .ucf doesn't use the same type of brackets as XST. Since the bracket style is a synthesis option, it's possible for the same source code to work in one project and not another. > : if you want to constrain a pin to a location, the tools will (usually) > : obey, if you do not care by not adding a location constraint why the > : tools should care, or maybe you want a mechanism which will guess that > : you actually forgot an entry into your ucf. > The tools don't need to "guess", either there is or isn't a ucf entry to match each IOB in the design. > What'd be really nice would be for the tools to let the user specify the > severity of a condition on a per project basis. So for example a non > LOCed IO could be flagged as 'no action', 'warning' or 'error' > > Given how many spurious warnings are often kicked out by the tools, it'd > be really usefull to have this as an integrated feature. > > cdsArticle: 103341
Mr. Ken wrote: > Thank you John_H. the 115/31 idea is interesting. I will make one and see > how much > resource it consumes. If resource consumption is fine, it will be greatly > increase the > precision of my design! The 115/31 was the strangest idea offered. If you need the result in a single clock, please look *seriously* at the simple multiplier. These are designed as library elements for very fast results and can easily accommodate your "one clock cycle" requirement. If your clock is 20 MHz, doing the 115/31 might be reasonable but it sure isn't single-clock friendly! Another consideration: does this value get used somewhere that you can algebraically manipulate the values so a /31 or /sqrt(21) can be "pulled in" to other number manipulation? PLEASE consider the multiplier.Article: 103342
Article: 103343
is there a standard way to combine state machines so that recurring tasks are implemented as a seperate machine and called when ever needed? something like reading and writing a RAM. CMOSArticle: 103344
just give some extra cclks to make sure that configuration process will finish (with dummy words) Aurash rickman wrote: > I'm having trouble configuring a Spartan 3 in parallel slave mode. The > mode pins are set with M0 tied to GND and M1,M2 left pulled up > internally to 2.5 volts. I verified these voltages with a meter. > > I am driving PROG_B low for a few microsecs then high. The DONE and > INIT_B signals go low and INIT_B goes high again. I set RDWR_B low and > start clocking data in by setting CS_B low and using the WR_N signal > from the DSP to clock CCLK on the trailing edge. I have looked at all > of these signals with the scope and they look clean and have good > timing. But no matter how much data we clock into the Spartan 3, we > never see either INIT_B go low or DONE go high. DONE has a 10 kohm > pullup resistor to 2.5 volts and a buffer converts this signal to 3.3 > volts for the DSP. > > I do see something odd on the BUSY pin. It goes high for some 800 ns. > The data sheet says I don't even have to monitor this pin if I keep the > CCLK rate below 50 MHz. We are clocking data into the part at less > than 10 MHz. > > Any idea what could be wrong? >Article: 103345
Thanks for your suggestion, but I already tried that. In fact, the software person put in an infinite loop writing "FF" to the device after all the config data was exhausted, which should have eventually either caused an error (INIT_B low) or driven the DONE pin high. That was when I looked at the BUSY pin and found it was going high for much longer periods than I would expect. Aurelian Lazarut wrote: > just give some extra cclks to make sure that configuration process will > finish (with dummy words) > Aurash > > rickman wrote: > > I'm having trouble configuring a Spartan 3 in parallel slave mode. The > > mode pins are set with M0 tied to GND and M1,M2 left pulled up > > internally to 2.5 volts. I verified these voltages with a meter. > > > > I am driving PROG_B low for a few microsecs then high. The DONE and > > INIT_B signals go low and INIT_B goes high again. I set RDWR_B low and > > start clocking data in by setting CS_B low and using the WR_N signal > > from the DSP to clock CCLK on the trailing edge. I have looked at all > > of these signals with the scope and they look clean and have good > > timing. But no matter how much data we clock into the Spartan 3, we > > never see either INIT_B go low or DONE go high. DONE has a 10 kohm > > pullup resistor to 2.5 volts and a buffer converts this signal to 3.3 > > volts for the DSP. > > > > I do see something odd on the BUSY pin. It goes high for some 800 ns. > > The data sheet says I don't even have to monitor this pin if I keep the > > CCLK rate below 50 MHz. We are clocking data into the part at less > > than 10 MHz. > > > > Any idea what could be wrong? > >Article: 103346
On 31 May 2006 06:16:59 -0700, "CMOS" <manusha@millenniumit.com>
wrote:
>is there a standard way to combine state machines so that recurring
>tasks are implemented as a seperate machine and called when ever
>needed?
>something like reading and writing a RAM.
>
>CMOS
Make this "recurring task" a black box with clock and start inputrs,
and end output.
You then modify the other state machine to start this black-box, and
wait for it to end.
You may even make your black-box slightly programmable, adding more
inputs that may modify its behaviour for some extent.
Typical example:
Some automatic system that may have to wait in some definite states
for different times. The black-box would then be, for instance, a
presettable down counter with clock enable.
(Traffic light controller:
STATE OFF.
when start order received, start down counter with a count of 10,
and goto RED
RED.
when count ends, start down counter with a count of 2, and goto
AMBER
AMBER.
when count ends, start down counter with a count of 8, and goto
GREEN
GREEN.
when count ends, start down counter with a count of 10, and goto RED
Best regards,
Zara
Article: 103347I may be missing something - I didn't read all 60 posts by John, but couldn't a LUT implementation work here? If he only needs limited precision in the final answer and his input data is at 9-bits, that's a 2^9 = 512 entry LUT. Assuming 16-bit output accuracy, we've got 1kB of data that will fit in a single BRAM.Article: 103348
Peter Alfke wrote: > Rob, you mntion that you do not use the FULL and EMPTY flags. > In that case, the asynchronous FIFO design becomes trivial. > Just have an address counter in each clock domain, and connect one to > the write port, the other one to the read port. No Gray counters, no > comparators, no anti-metastable re-synchronizers. All that complexity > is only needed to generate reliable flags. > > Timing constraints that cross the clock domain are inherently > meaningless, since there is no fixed timing relationship. > Peter Alfke,Xilinx (from home) Yes, I can get away without using those flags, but I do use the VALID flag for reading. Surely that is just NOT( EMPTY ) and so requires the same precautions? RobArticle: 103349
Hi all, my hardware guys are on vacation but I need to clarify this: The EDK soft cores like opb_ethernetlite need the MAC address as parameter. They do not provide a unique MAC address as default. You can imagine, what management effort would be necessary to maintain a unique MAC address for every device we deliver. Is there any MAC address available at the Virtex-4FX12MM that - is unique for every board - is accessable (read-only) by the PowerPC where our code runs Maybe the hard_temac core? Thank you for help on this!
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