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
Davy schrieb:
> Hi,
>
> Thank you for your help :-)
>
> Do you think what's the best way to generate delay smaller than a clock
> period?
>
> Best regards,
> Davy
>
Hi Davy,
unfortunately you didn't tell why you want to create such a delay.
That would help to give you useful help.
One solution may be to feed the signal into a DFF that is clocked by the
falling edge of your clock signal (assuming that the rest of your
circuit uses the rising edge). Thus you get a delay of half a clock period.
Another way could be constraints. While max_delay constraints are
available I'm not sure about min_delay constraints.
The problem with combinatorical delays in FPGAs is that they are
somewhat meaningless, since the routing delays between the LUTs are much
higher and (unless propperly constrained) not predictable. So this
approach is probably the worst choice, sice it is wasting LUTs for no
reason.
Have a nice synthesis
Eilert
Article: 93226Hi, First time poster here. I'm using Xilinx's cheap Spartan 3 Starter Kit Board to create a simple VGA "controller" (framebuffer output) that I want to interface to 8051 and Z80 systems I've constructed myself (breadboard projects.) I'm having serious trouble implementing writes to the on-board SRAM because there appears to be some sort of conflict with the display refresh which causes data to occasionally be misplaced in the frame buffer (several dozen pixels per frame.) After a couple weeks (!!) of debugging and experimentation (too much stuff to list in this first post), I believe I've narrowed the problem down to one of the following issues: 1. Writes are supposed to pre-empt reads in my VHDL state machine. Perhaps there is some sort of conflict. If there is, it is not obvious. My state machine is pretty tight and unless the toolchain is synthesizing glitchy logic, there should be no problem. 2. Data is input from the external CPU (Z80 or 8051) via a simple 5-bit port: 3 bits of color data, an address pointer reset bit, and a clock bit. The Z80 will write a 0 and then a 1 to the clock bit and on the rising edge of this pin, the FPGA is to latch the data and initiate a write. It appears that the transition from low-to-high may be problematic for the FPGA or once a write is complete, the internal signal is not deasserted quickly enough (but this really shouldn't cause any problems -- it would just write over and over again to the same spot.) I've tried to sync the input pin clock to the FPGA's 50MHz clock (which my state machines run off of) but no luck there. 3. My 2-cycle write sequence to SRAM might be wrong. But I doubt it because I've verified it against working code and I've synthesized simpler circuits which prove that RAM is being read and written correctly. I've tried a number of things including adding a pin to disable the display (thus stopping all reads) which the Z80 can control. Even when the display is off and I write to the FPGA, these bad pixels appear. It's not physical noise, that's almost for sure. The pixels are always colored the same as in the image -- in fact, they're often missing from the image and moved somewhere else. Here's some of the relevant VHDL (I hope the formatting is preserved, I'm using Google Groups): (Please note how I am clearing the sram_do_write signal -- I think this may be part of the problem but there's no easy way to rectify it.) process(input) begin if input(4)'event and input(4) = '1' then if input(3) = '1' then -- reset address write_addr <= "000000000000000000"; else sram_data_write(2 downto 0) <= input(2 downto 0); sram_write_addr <= write_addr; write_addr <= write_addr + 1; sram_do_write <= '1'; end if; end if; if sram_state = SRAM_WRITE then sram_do_write <= '0'; end if; end process; -- -- SRAM State Machine -- process(clk_50mhz, sram_do_write, sram_do_read, sram_write_addr, sram_read_addr) begin sram_oe <= '0'; if clk_50mhz'event and clk_50mhz = '1' then case sram_state is when SRAM_WAITING => sram_read_done <= '0'; sram_write_done <= '0'; if sram_do_write = '1' then -- write requested sram_addr <= sram_write_addr; sram_ce <= '0'; sram_we <= '0'; sram_io_t <= '0'; sram_state <= SRAM_WRITE; elsif sram_do_read = '1' and sram_do_write = '0' then -- read requested -- -- Address in sram_addr and data will be read to -- sram_data_read. -- sram_addr <= sram_read_addr; sram_ce <= '0'; sram_we <= '1'; sram_io_t <= '1'; sram_state <= SRAM_READ; else sram_ce <= '1'; sram_io_t <= '1'; end if; when SRAM_READ => sram_ce <= '1'; sram_we <= '1'; sram_io_t <= '0'; sram_data_read_buf <= sram_data_read; sram_read_done <= '1'; -- finished reading sram_state <= SRAM_WAITING; when SRAM_WRITE => sram_ce <= '1'; sram_we <= '1'; sram_io_t <= '0'; sram_write_done <= '1'; sram_state <= SRAM_WAITING; end case; end if; end process; Any suggestions would be greatly appreciated!Article: 93227
In general, ISE 8.1i seems to install and work just fine on my Athlon 64 system running Fedora Core 4 (64-bit). ISE Simulator does not seem to get installed, though. I'll try installing on a 32-bit system later and see if that gets it. And unfortunately there still aren't 64-bit cable drivers for use with the Parallel Cable IV or the Platform Cable USB. I started trying to build them myself from the Xilinx "sources" and the Jungo demo kit, but Xilinx supplies the core of the XPC4 driver as a binary archive, and they don't supply a 64-bit version of that. Sigh. Could we have some 64-bit cable drivers, pretty please? It's nice being able to run Project Navigator and do everything up through the programming file generation on my main development machine, instead of needing a second machine with very old software (RHEL3) for that. But it looks like I'll still need a second machine to run Impact. I'm considering buying Chipscope, but I think I'll hold off until there are 64-bit cable drivers.Article: 93228
"Bart" <bart_trzynadlowski@yahoo.com> schrieb im Newsbeitrag news:1134717308.862664.31090@o13g2000cwo.googlegroups.com... > Hi, > > First time poster here. I'm using Xilinx's cheap Spartan 3 Starter Kit > Board to create a simple VGA "controller" (framebuffer output) that I > want to interface to 8051 and Z80 systems I've constructed myself > (breadboard projects.) > [snip] generic advice, if in such trouble as you are then it is usually VERY helpful to "look" into the FPGA, so get the ChipScope eval, add the ILA to some of the signals and look whats actually happening. you can use one DCM to get say 150MHz and use that ILA clock so you would see several samplings per each system clock sample AnttiArticle: 93229
Dear Sir, There have a Xilinx/Nallatech Virtex4 development board beside me, on which there has 2 ch ADC (105MSPS), 2ch DAC, FPGA Vritex4 XC4VSX35-10FF668. There have poor examples from Nallatech, and I really don't like the interface FUSE. I am using the USB port to communicate with this board, and if I want to configure the FPGA chips through USB, FUSE seems the only way? (or I write the dirver for USB interface). Is it possible to configure through JTAG directly in ISE? I plan to make the board running, for example, a simple signal generator, or digital filter. Can you give me some detailed instruction on it? I am not good at HDL, good example start from ISE is very helpful. Thanks wilsonArticle: 93230
Hi Eric, Did you get the drivers of ISE7.1i 32bits work on FC4-32bits at full speed? MehdiArticle: 93231
GaLaKtIkUs wrote:
> Did you get the drivers of ISE7.1i 32bits work on FC4-32bits at full
> speed?
I didn't try. I set up a system running CentOS 3.5 32-bit (though it's
64-bit hardware), and 7.1i worked fine on that, including cable drivers
(after I compiled them).
So now I have a Belkin 4 port USB-and-DVI KVM switch, and go back and
forth between that and my main development machine (FC4 64-bit). That
KVM switch is a total piece of crap, buy the way, so don't buy one.
(Details below for the curious.)
Now that I'm using 8.1i, I might try installing FC4 32-bit on that
machine instead. Aside from the cable drivers and ISE simulator, 8.1i
installed beautifully on FC4 64-bit, with none of the hassles for
different versions of shared libraries and special environment variable
settings that were needed for 7.1i.
But I *really* would much rather be able to program from my main
development machine. I briefly considered trying to reverse-engineer
the ioctl_3.a file, but I suspect that would violate the ISE license
agreement, and anyhow, life's too short.
It's hard to believe that there are any significant trade secrets in
ioctl_3.a; maybe Xilinx can be convinced to give out the source for it.
Eric
Belkin 4-port USB-and-DVI KVM problems:
1) mechanical - can't plug the DVI cable onto port 1 of the KVM due
to lip of plastic housing, effectively making it a 3-port KVM
2) electrial - rather than having four DVI receivers, a mux, and
a DVI driver, the KVM uses *relays* to switch the DVI signals.
This results in enough signal degradation that I occassionally
get twinkling pixel streaks. Ugh.
3) firmware (?) - the KVM sporadically loses key events. Sometimes
pressing a key does nothing, and sometimes a key up event is lost,
so the key starts repeating even though it's been released.
I wouldn't have gotten the KVM switch at all, since I can use X over
the network easily enough, but while I was trying to get drivers working
I was rebooting the machine frequently and needed to see the screen
during the boot process.
Article: 93232"Eric Smith" <eric@brouhaha.com> schrieb im Newsbeitrag news:qhr78da1qd.fsf@ruckus.brouhaha.com... > GaLaKtIkUs wrote: >> Did you get the drivers of ISE7.1i 32bits work on FC4-32bits at full >> speed? > > I didn't try. I set up a system running CentOS 3.5 32-bit (though it's > 64-bit hardware), and 7.1i worked fine on that, including cable drivers > (after I compiled them). > > So now I have a Belkin 4 port USB-and-DVI KVM switch, and go back and > forth between that and my main development machine (FC4 64-bit). That > KVM switch is a total piece of crap, buy the way, so don't buy one. > (Details below for the curious.) > > Now that I'm using 8.1i, I might try installing FC4 32-bit on that > machine instead. Aside from the cable drivers and ISE simulator, 8.1i > installed beautifully on FC4 64-bit, with none of the hassles for > different versions of shared libraries and special environment variable > settings that were needed for 7.1i. > > But I *really* would much rather be able to program from my main > development machine. I briefly considered trying to reverse-engineer > the ioctl_3.a file, but I suspect that would violate the ISE license > agreement, and anyhow, life's too short. > > It's hard to believe that there are any significant trade secrets in > ioctl_3.a; maybe Xilinx can be convinced to give out the source for it. > Xilinx is trying to keep the Cable IV internals as secret so thats why they dont release in source code anything that could include information how to talk to the cable IV in high speed mode. And that is also the reason why there Cable IV support is as shit as it is. On my main computer where all ECP port cable from other vendors work properly, well Cable IV works in Cable III emulation mode only. Its an WinXP machine so the problems are not only on linus BTW the Cable IV PLD is non protected and resoldering a few 0 ohms on the PCB makes Impact able to read back the JEDED file from the XC3384, and I have a tool that converts the JEDEC to synthesizeable VHDL :) AnttiArticle: 93233
Symon wrote: >> And you only really have to elevate it above the cost of bribing one of >> your employees :) >> But you don't want to make it so hard that your competitors resort to rubber-hose cryptanalysis. > Jim, > That's a key insight! I read Kevin Mitnick's books recently. Although the > security breaches he writes about involved an amount of technical > engineering knowledge, the social engineering undertaken was usually the key > to unlock the first door! > Cheers, Syms. > > "The Art of Deception" should be required reading for anyone involved in security.Article: 93234
Hi Sudhir, thank you for detailed answer. If I do that the manner you describe I also get that residuum when using the easics-module (CRC-Reset Value (OTHERS =3D> '1')). But I wonder what the IEEE Std. 802.3 (section 3.2.8 Frame Check Sequence field) means when claiming a)The =EF=AC=81rst 32 bits of the frame are complemented. Do you have any idea ? Rgds Andr=C3=A9Article: 93235
Peter Alfke wrote: > Ages ago, IC manufacturers used to specify a max ambient temperature > (70 degr.C for commercial parts). We soon found out that this makes no > sense for programmable parts. The FPGA manufacturer does not know what > the user implements inside the chip (what clock frequency, what > utilization) and how the chip is cooled. The only reasonable > specification that we can guarantee is the max junction temperature. So > we pioneered the Tj max 85 degr.C specification for all commercial > parts. > The user is the only person who then can evaluate whether the chip is > operating within these guaranteed limits, and can modify the design or > the cooling to bring it within specification. > It would be nice if the FPGA-manufacturer could guarantee operation at > a given ambient temperature, but that is inherently impossible, > especially for parts where the user can program the logic and choose > the clock speed. > As a rule of thumb, no package without a heatsink has a thermal > resistance (junction-to-ambient) below 10 degr.C per Watt. ( the very > biggest get down to 8 degr./W), and a heatsink is needed when power > exceeds a few watts. > Peter Alfke, Xilinx Applications For all the VLSI devices I have used in the last few years, the maximum temperature ratings were die temperature, not ambient for the reasons you specify. As VLSI power dissipation is very dependent on operating mode, ambient ratings are pretty meaningless not only for programmable parts, but for the majority of VLSI. Things become quite difficult when the mfr has neglected to put a thermal sensing diode (really a transistor) on the die somewhere. I suggest the OP grab the rather useful power dissipation calculator from the Xilinx website and then apply it using the Theta J-A for the device he is using. Cheers PeteSArticle: 93236
ALuPin@web.de wrote: > Hi Sudhir, > > thank you for detailed answer. > > If I do that the manner you describe I also get that residuum when > using the easics-module (CRC-Reset Value (OTHERS =3D> '1')). > > But I wonder what the IEEE Std. 802.3 (section 3.2.8 Frame Check > Sequence field) > > means when claiming > a)The =EF=AC=81rst 32 bits of the frame are complemented. It means exactly what it says. You invert the first 32 bits of the frame. I listed a number of CRC properties in this thread: http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/587b14d0fc4= 3dbc1/cf1e7d94dedc5733#cf1e7d94dedc5733 Property 3 says: " Initialising the register to all ones is equivalent to initialising the register to all zeros and *inverting the first N bits of the message*." Regards, AllanArticle: 93237
hello group! (and sorry for the cross-posting) I am working on a complex FPGA prototype and have already a feeling that the usual "testbench verification" wont help very much here. I have worked with formal verification in past and think this is a great opportunity to introduce the team to FV. I couldn't get the management to pay for new verification software, so i decided to ask the experts (you guys) if any good but "free" verification tools are available. I am even interested in academic type of software (=working but user unfriendly). For example, i could go for SMV if i could figure out a way to feed it VHDL or compiled netlists. Of course, it does not have to be "formal" verification. I could go with any tool available as long as it gets the job done. So please help me find the right tool for this job. You may also take this as a great opportunity for you guys to promote your software or share your experiences with the world! regards, BurnsArticle: 93238
>It means exactly what it says. You invert the first 32 bits of the >frame. Note that you get the same results if you initialize the CRC register with all ones and do not complement the first 32 bits, due to the properties of the CRC algorithm. Inverting the first 32 bits (or equivalently using a start valuie of 0xFFFFFFFF) detects erroneous 0s inside the start sequence (first 32 bits). If you initialize with 0 and have additional 0s at the beginning, standard CRC will not detect it (CRC uses polynom division, dividing 0 always gives 0). Hubble.Article: 93239
Hi Allan, hi Reiner, thank you for your responses. They have shed some light on my problem. I have simulated the test design with respect to your considerations and they are correct.=20 Thanks again for your help. Rgds Andr=E9Article: 93240
Hi Sudhir, >The result in the CRC register after the last byte has gone through >is called the residue, and in the > case of 802.3 it is 0xC704DD7B Yes, the simulation shows that. Rgds Andr=E9Article: 93241
Davy wrote: > Hi, > > Thank you for your help :-) > > Do you think what's the best way to generate delay smaller than a clock > period? > > Best regards, > Davy If you have a steady clock in the right frequency range for your device, you can use a PLL, DLL, or DCM to get a different delay than 1.0 or 0.5 clock periods. The DCM especially allows you to set up a shifted clock with 1/256th of a clock resolution (or about 50 ps, whichever is greater) of delay. This precisely delayed clock can give you the precision control over skew that today's designers need. If you're in Virtex-4 devices, the inputs have per-pin controllable delays that are calibrated to give you 78 ps delay resolution on unclocked signals. So - is your device able to supply the fun stuff? More application details can bring out the info on the "best" feature set to use.Article: 93242
Alex Gibson wrote:
> According to
> <http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D27812%2526CCD%253DUSA%2526SID%253D4742%2526DID%253DDF2%2526SRT%253D1%2526LID%253D18806%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html>
>
> The spartan 3e starter kits are available yet xilinx says they are not ?
>
> Alex
If you hit the "Buy Now" button the following info pops up:
* Lead Time (weeks): Call
* Status: NCNR, Backorder
Maybe Xilinx is doing it better by saying "Notify me when available" in
blace of "Add to Cart."
There's still no information on the Avnet site beyond the one-page
product brief. At least it *looks* like an S3E board! Now if I could
read those connector part numbers....
Since - at the moment - the Xilinx link
http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=DO-SPAR3E-DK
is dead, there may be an imminent update.
Article: 93243"John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag news:irAof.3$Ht4.2@trnddc08... > Alex Gibson wrote: > >> According to >> <http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D27812%2526CCD%253DUSA%2526SID%253D4742%2526DID%253DDF2%2526SRT%253D1%2526LID%253D18806%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html> >> >> The spartan 3e starter kits are available yet xilinx says they are not ? >> >> Alex > > If you hit the "Buy Now" button the following info pops up: > > * Lead Time (weeks): Call > * Status: NCNR, Backorder > > Maybe Xilinx is doing it better by saying "Notify me when available" in > blace of "Add to Cart." > the avnet 100e board is still in stock, surprisingly the stock count have increased from 18 to 83 ?? with lead time of 26 weeks...!? > There's still no information on the Avnet site beyond the one-page product > brief. At least it *looks* like an S3E board! Now if I could read those > connector part numbers.... > > Since - at the moment - the Xilinx link > http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=DO-SPAR3E-DK > is dead, there may be an imminent update. we need to wait then :( anttiArticle: 93244
John_H wrote: > > There's still no information on the Avnet site beyond the one-page > product brief. At least it *looks* like an S3E board! Now if I could > read those connector part numbers.... > The high speed connnector is the same one as used on the Digilent/Xilinx XUPV2P board: http://www.xilinx.com/univ/xupv2p.html http://www.digilentinc.com/info/XUPV2P.cfm The softtouch connector footprint routing pictured in the Avnet datasheet appears to indicate there's provision for at least some differential pairs to the connector, have to wait for the released schematics and layout files to be sure. BrianArticle: 93245
Hello! Having finished a board design with a Virtex-4FX and with promising leads on the silicon, I sat down to begin my HDL coding... when I discovered that the simulation models for the Virtex-4 PPC and MAC components are only available in encrypted form. After poking around a bit on the net and usenet, it seems that only the really high-end simulators can support these encrypted models. Has anyone found an inexpensive HDL simulator which supports these encrypted models, or any other way to design with the cool features of the Virtex 2-pro and Virtex-4FX? Thanks, ...EricArticle: 93246
Bart - Have you checked the quality of the input(4) signal? If it is slow or has noise, glitches, etc the ram write address could get incremented multiple times for each write operation. Also, you mentioned trying to synchronize the sram_do_write signal to the 50MHz clock - you must do that! Otherwise, you've got an async signal feeding into your state machine - just a matter of time before it screws up. Hope this helps! John ProvidenzaArticle: 93247
Davy wrote:
> Hi,
>
> I work on Xilinx ISE, and my synthesis tool is XST and synplify.
> I use verilog to write a Inverter Chain (delay ) like out =
> ~(~(~(~...in)).
> But the circuit be synthesised cancel all the invorter.
>
> How to synthesis out all the inverter chain I want?
>
> Any suggestions will be appreciated!
> Best regards,
> Davy
>
For synplify tools,
wire [3:0] inv_chain/*synthesis syn_keep=1*/;
assign inv_chain[3:0] = ~{inv_chain[2:0], din};
assign dout = inv_chain[3];
I'm not use what XST uses in equivalence to syn_keep. It might be the same.
Like other ppl pointed out, you shouldn't expect to use invertor chains
for any precision timing control. There are just too many uncertainties
in FPGA. But if you just want to insert some combinational delay to
solve some racing conditions, it might come in handy.
cheers,
jz
Article: 93248
Hi kl31n,
> My design requires me to acquire data from an ADC and then,
> after some processing to do a division between a couple
> floating point numbers every 200ns.
> The performances of the core aren't big enough to use just
> one, so I implemented a core which feeds several dividers
> (made with the Xilinx core) and then I reserialize it all.
What exactly is your performance requirement? How often do you need to start
a new divide operation? How long can you afford to wait for the result?
The Xilinx speed-optimized floating-point divider will run at well over
250MHz and allows you to initiate a new divide on every cycle (i.e. every
4ns) if you wish.
> The design works fine till I pass numbers with a period
> down to 260ns, going for lower periods the results get weird
I'm afraid I don't understand what you mean by "pass numbers with a period
down to 260ns", could you explain your circuit to me?
-Ben-
Article: 93249I would suggest to try to get a simplified system to run at first. Use internal SRAM as frame buffer. This will not be enough for full screen, but that does not matter at first, considering the magnitude of your difficultied. The internal SRAM is dual ported so you can write with one state machine and read with another, using different clocks. If you still see problems, it is very likely that the quality of the input signal is the problem. If not, you have a problem with synchronization or SRAM access. Try to think of a design change that can separate the two. Kolja
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