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
jbnote, See answers in line below, Austin -snip > Sorry for not reading the docs, is encryption only used on frame data > in the bitstream? Encryption is used for the "bitstream", but not for configuration commands. CRC32 check is a command. Startup is a command. > - If encryption is for the full bitstream, then there's not even one > chance that the random garbage will make sense to the bitstream > microcontroller, so you're safe. It is unlikely that an attacker can change what they want to cause a specific result, as CBC will corrupt the following block(s) as well. If they already knew the design, then they don't need to un-encrypt the bitstream, do they? If they just wish to break it, use a hammer. If they wish to insert their own program, NOTHING prevents that (we accept all bitstreams, a true equal opportunity employer). > - If encryption is limited to the data stream, then on the virtex2, > it's very easy to disable CRC checking and load random garbage for > which I'd guess frying configurations on long lines would not be > uncommon (let's do the math !). Yes, you can just skip the CRC check, and startup anyway. Virtex 2 and later devices are unlikely to "burn up" but they may be some contention. > On virtex4 and virtex5, I'd expect that each frame's Hamming SECDED > code is checked by the loading state machine and encrypted, so random > garbage would be rejected ? Or does Hamming Code sits there for nothing > at load-time ? Oh, that would be nice, but no, the bits do nothing of the sort. If you wished, you could use those bits for a watermark, or some other reason. Just because we call them the frame syndrome bits doesn't really make them special (until you want to use the FRAME_ECC feature).Article: 114751
Austin Lesea wrote: > Brian, > > http://tinyurl.com/367qnf > > Details the technical answer on this subject. > > Austin I am a long time lurker on this newgroup and have learned a lot from it. I very much appreciate the presence of Austin and Peter and the help that they provide. However, what got me to post this is that the url above just adds insult to injury regarding ise. I am a long time user of Xilinx software starting in about 1991. For most of that period the software has been terrible. The XACT software required you to reboot after every run, either voluntarily or it would do it for you. By the time of the Foundation series, the software was getting reasonable. I even bought a copy for my personal use. ISE has been an experience. By version 6.3 it was reasonably good. It did what I wanted and did not cause too much trouble. Version 7 was a huge step backwards. Project navigator got user surly and very slow. Whoever did the design never used it for anything. Version 8 reached a new low. The stupid design to change the project files, later partly removed, made for lots of headaches. Fortunately I was spared a lot of the headaches of version 8 since it would not compile my design. For a variety of reasons, mostly historical, a large part of my design is schematics. There is a major memory leak in the schvhdl module. It leaks at about 1mb per second of cpu time. Version 7 would complete the xst portion in about five minutes with a peak memory useage of around 120mb. Version 8 took an hour or so of time and then crashed at just over 2gb of useage. There was no way to compile the project and this was confirmed by Xilinx tech support. The only "workaround" was to tell it to compile to verilog instead of vhdl since that memory leak was not as bad. Unfortunately this was not an option since the peak memory useage was just about the 2gb point where the vhdl conversion failed and blew up the program. The memory leak was a problem in version 8.1 It was not fixed in 8.1 sp1 It was not fixed in 8.1 sp2 It was not fixed in 8.1 sp3 It was not fixed in 8.2 It was not fixed in 8.2 sp1 It was not fixed in 8.2 sp2 It was not fixed in 8.2 sp3 It was not fixed in 9.1 It was not fixed in 9.1 sp1 So the latest and greatest version 9.1 and its service pack have done nothing to help make a relatively small design work. If they are not going to improve things, why break stuff that was working ok? Memory leaks come from sloppy programmers. Not fixing memory leaks comes from lazy or incompetent programmers. It is clear that the programmers did not test their code. They seem to think that "testing" means looking to see if it blows up in the first ten seconds. This is not some exotic hard to reproduce bug. Take an 2 input and gate and put iopins on it. The memory leak is about 3mb as I recall. This is not subtle or hard to find. They did not even look. They have not been looking since it was pointed out and there is no reason to believe that they have any intention of looking for the leaks. At one point I sent in a list of fourteen bugs in ise for version 7. They are all still there plus lots of new ones I have seen in the little I have been able to use the newer versions. The conclusion of this is that pointing to a url which just points out that the programmers did not bother to test their code does not help the users. What is needed is to get programmers who know what they are doing and FIX the problems. Xilinx support recommended vhdl as it is more portable. That is true and will make it easier to take designs to other manufacturers.Article: 114752
Austin Lesea wrote: > Kunil, > > http://www.xilinx.com/products/design_resources/power_central/ > > Use the "XPower Estimator" tool to find the intended power requirements. > > Then scroll down to "Partners" > > and pick your favorite vendor. > > Follow the links. > > Really quite simple. Not sure why others are making such a big deal out > of this. It is really a trivial issue. The power requirements which > require very low noise, are the MGT analog supplies, and there is a huge > user's guide to help you there (as well as manufacturer part numbers, > and sample schematics). > > Every one of these vendors has met with Xilinx, and had their products > reviewed. These vendors are used on our own boards. > > The only really difficult part is estimating the power you will use, > because we have no control over what you program into our parts. All we > can do is provide the tools to make estimates (which are based off the > quality of information you give them). So, if you put garbage in, you > get garbage out. > > Austin Now I'm home.... Hmmm - it's not a big deal if a design is strictly specified and simulated long before it's laid out. That may be possible (indeed, is, I am sure) within Xilinx (and all the other vendors), but out here in productland the PCB designer is left with, at best, a [hopefully educated] guess simply because the design is nowhere near complete before the board goes to layout. I prefer at least a SWAG to a mere WAG. By that time, the power has to be specified of course. That's why I overspecify it (I have a specific bag of tricks I use for Xilinx FPGAs just as I have them for other vendors) based on core size, IOs, IO speeds I expect etc., but I don't normally get power estimates from the FPGA designer (when it isn't me) until long past the time it would be useful for the original design stage. Then there's feature creep. What happens if I specify the core power minimally (from a design) to save money and then I suddenly find we're going to drop a high speed arbitrator into the device ?(your choice of a large piece of functionality here). I'm sure I am not the only one that has to deal with that, but it is the reality of product design, whether we like it or not. My answer is to have power designs that cover the worst case for all three of VIO, Vcore and Vaux. Cheers PeteSArticle: 114753
PeteS wrote: > Austin Lesea wrote: >> Kunil, >> >> http://www.xilinx.com/products/design_resources/power_central/ >> >> Use the "XPower Estimator" tool to find the intended power requirements. >> >> Then scroll down to "Partners" >> >> and pick your favorite vendor. >> >> Follow the links. >> >> Really quite simple. Not sure why others are making such a big deal out >> of this. It is really a trivial issue. The power requirements which >> require very low noise, are the MGT analog supplies, and there is a huge >> user's guide to help you there (as well as manufacturer part numbers, >> and sample schematics). >> >> Every one of these vendors has met with Xilinx, and had their products >> reviewed. These vendors are used on our own boards. >> >> The only really difficult part is estimating the power you will use, >> because we have no control over what you program into our parts. All we >> can do is provide the tools to make estimates (which are based off the >> quality of information you give them). So, if you put garbage in, you >> get garbage out. >> >> Austin > > Now I'm home.... > > Hmmm - it's not a big deal if a design is strictly specified and > simulated long before it's laid out. That may be possible (indeed, is, I > am sure) within Xilinx (and all the other vendors), but out here in > productland the PCB designer is left with, at best, a [hopefully > educated] guess simply because the design is nowhere near complete > before the board goes to layout. I prefer at least a SWAG to a mere WAG. > > By that time, the power has to be specified of course. That's why I > overspecify it (I have a specific bag of tricks I use for Xilinx FPGAs > just as I have them for other vendors) based on core size, IOs, IO > speeds I expect etc., but I don't normally get power estimates from the > FPGA designer (when it isn't me) until long past the time it would be > useful for the original design stage. > > Then there's feature creep. What happens if I specify the core power > minimally (from a design) to save money and then I suddenly find we're > going to drop a high speed arbitrator into the device ?(your choice of a > large piece of functionality here). > > I'm sure I am not the only one that has to deal with that, but it is the > reality of product design, whether we like it or not. > > My answer is to have power designs that cover the worst case for all > three of VIO, Vcore and Vaux. > > Cheers > > PeteS I would hasten to add that the power estimator is a great tool, even after the fact, to help with overall board power calculations (where thermal issues might be handled after layout). Cheers PeteSArticle: 114754
Sorry, I only check in here when I get really bored... :) On 20 Jan 2007 10:43:16 -0800, "spectrallypure" <jorgelagos@gmail.com> wrote: >Thanks so much for your reply, Paul. Here I add some information: > >> #1 - Why is one signal rising at 10264ns, and the other at 10263ns? >As I told before, i just can't figure out why there are differences in >the the timming of the signals. What puzzles me the most is that even >the signal SHIFTWR (which is generated by the testbench and has nothing >to do with the synthesized netlist whatsoever) changes its timming, >presenting its rising edge @ 8463ns and @ 8487ns, respectively. Clearly >this is unexpected behavior. I have no clue of what could be the reason >nor how to trace it back... Cut down your test bench, don't instantiate your device, see if you can confirm that SHIFTWR timing changes even without the synthesised netlist. I doubt it, but you will need to fix this first if you're right. If this really *is* the case, then there's almost certainly an error in your testbench, which will probably be either a race condition or a timing resolution problem. If it's not obvious (it should be), manually check the timing on whatever logic drives SHIFTWR. At some point, you should find that the numbers start diverging between 5.8 and 6.2. This will be very tedious, but you should manage it within a few hours. You're in trouble if you don't understand race conditions. Google comp.lang.verilog; you'll find a huge number of posts on it. If this is a school project, as I suspect it is, then you should probably give up. If it's a real project and you actually need a fix, then I'm afraid that you're probably going to have to pay someone to sort it out. Running PrimeTime and back-annotated ASIC timing sims is not a job for beginners. Reply if you're interested, and I'll send you my real email address. >In 5.8b I get a lot (nearly 50,000) of the following warnings: > ># ** Warning: (vsim-SDF-3262) ./DFM_TC_Worst.pt.sdf(<-SDF line number >here->): Failed to find matching specify timing constraint. Rule #1 when you get an error message you don't understand: Google it. Ther are some exact matches on your error message, which suggest that you might not have recompiled your simulation libraries when changing ModelSim versions. For ModelSim, you always need to recompile libraries when changing major version numbers. /PJArticle: 114755
On 2007-01-23, stephen.craven@gmail.com <stephen.craven@gmail.com> wrote: > Does anyone know if it is possible to permanently harm a Xilinx FPGA > internally through a bad (accidental or malicious) bitstream? One totally unobvious one is: http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=22471 Running without an MGT hooked up for 400 hours might cause it to permanently fail! -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 114756
On Jan 22, 12:33 am, "Sylvain Munaut <Some...@SomeDomain.com>"
<246...@gmail.com> wrote:
> Here's my problem :
>
> A have a video module (that I can't really change), that outputs a
> 3840x2400 image, by outputing two consecutive pixels at once (like
> dual-link DVI). The problem is that the screen to display that doesn't
> want dual-link DVI, it wants two independant DVI stream, one for the
> left part of the screen and another for the right part of the screen.
> (two "stripes" of 1920x2400).
> I'm trying to come up with a solution to "transform" one into another,
> without using a frame buffer nor storing more than 1 line of video.
> (At 3840, in color, that already is 6 Xilinx BRAMs and I'm a little
> short of those ...).
> According to my calculations, It should even be possible to only store
> half a line, but I prefer to have a 1 line delay than half a line
> delay.
> My problem is that I can't find how to do it ... Storing in BRAM has
> proven to be an addressing nightmare
Nobody has provided what you really want here yet.
I sympathize with the need to conserve BRAM in video applications.
Maybe we can turn your nightmare into a sweet dream.
> to store and reread simultaneously
> without overwriting data I haven't re-read yet ... (since I don't read
> in the same order that I write).
>
> Does anyone has done something similar or has a genius idea ? Because
> I'm missing something here, that should be simple and I just don't see
> it ...
>
> Sylvain
Sylvain,
The approach to solving your addressing dilemma is to start small.
Look at a line that is only 12 pixels long. On your first pass you will
write to these locations:
| first half line | second half line |
0 1 2 3 4 5 6 7 8 9 10 11
On your next line, you want to Read before Write these locations:
0 6 1 7 2 8 3 9 4 10 5 11
Continuing this pattern gives:
0 3 6 9 1 4 7 10 2 5 8 11
0 7 3 10 6 2 9 5 1 8 4 11
0 9 7 5 3 1 10 8 6 4 2 11
0 10 9 8 7 6 5 4 3 2 1 11
0 5 10 4 9 3 8 2 7 1 6 11
0 8 5 2 10 7 4 1 9 6 3 11
0 4 8 1 5 9 2 6 10 3 7 11
0 2 4 6 8 10 1 3 5 7 9 11
0 1 2 3 4 5 6 7 8 9 10 11
and voila, you're back where you started.
Now how do you produce these numbers?
Let the magic of modular arithmetic help you.
Below is a perl script that generates the sequences you need, and shows
everything you need to do. It takes one accumulator and one counter, an
addition, a comparison, and optional subtraction. Limit may be
programmable since you want to handle arbitrary line lengths right?.
You have not mentioned what clock rate you have, but if you translate
this into VHDL, you may even be able to get the addition, comparison,
and optional subtraction into a single cycle. If not, then you can
double the width of the BRAM inputs/outputs using external registers,
demuxes/muxes until you have enough time to do the requisite modular
addition.
I expect this is what you wanted,
HTH
Just John
Herewith, the perl script...
#!/bin/perl
use strict;
my $Limit = 11; # One less than line length
my $Middle = $Limit >> 1; # Routing operation
my $Loop = $Limit + 1;
my $NewIncr = 1;
while ( $Loop-- ) { # Loop over lines
# printf "Loop %2d:", $Loop;
my $Incr = $NewIncr;
my $Addr = 0;
my $C = 0;
while ( $C != $Limit ) { # Loop over pixels in lines
printf " %2d", $Addr;
$Addr += $Incr;
$Addr -= $Limit if ( $Addr > $Limit );
$NewIncr = $Addr if ( $C == $Middle );
$C++;
}
printf " %2d\n", $Limit;
}
Article: 114757On 2007-01-23, blisca <> wrote: > maybe i'm too drunk after soldered tiny wires with cheap lens on the bottom > of this BGA > > so i did this almost senseless question Drunk is the right state to use iMPACT. For example, if you go back and forth between writing .bit's into FPGAs and .mcs's into Xilinx config proms, you will want to stab someone each time you forget to turn ON erase/verify/use-internal-config-clock for the PROM because iMPACT mysteriously forgot those settings... AGAIN -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 114758
Rob, since you mentioned XILINX BRAM architecture: Yes, each BlockRAM has two ports that are compltely independent. On each port, during a write operation, you can read the previous content of the memory word that you are just now writing into. This is a configuration option: either read the old content, or the new content, or leave the output word untouched. Peter Alfke, Xilinx Applications On Jan 22, 7:20 pm, "Rob" <robns...@frontiernet.net> wrote: > Sylvain > > I'm not familiar with Xilinx's memory architecture; but if their memory blocks have the option of being run in dual-port mode it could make this problem much easier to deal with. > > In the past I've taken advantage of other mfg's mixed-port read-during-write mode. This mode is used when a RAM has one port reading and the other port writing to the same address location with the same clock. The memory block outputs the old data at the specified address when there is a simultaneous read during write to the same port. You then could set up two blocks (one for each half of the image) a line deep. > > First fill the memory blocks with line 1 > > fill block a > > *reset wraddr_a back to addr 0 and wait for block b to fill > > fill block b > > reset wraddr_b back to addr 0 > > now you read through the two blocks simultaneously while writing to the same address for block_a > > reset wraddr_b back to addr 0 > > repeat * > > You'll have two pointers for each memory block, one read and one write pointer. > > I haven't done any work with DVI so I may be missing something specific to that interface. If so, my apologies. > > Take care, > > Rob > > "Sylvain Munaut <Some...@SomeDomain.com>" <246...@gmail.com> wrote in messagenews:1169454808.249472.167130@a75g2000cwd.googlegroups.com... > > > Here's my problem : > > > A have a video module (that I can't really change), that outputs a > > 3840x2400 image, by outputing two consecutive pixels at once (like > > dual-link DVI). The problem is that the screen to display that doesn't > > want dual-link DVI, it wants two independant DVI stream, one for the > > left part of the screen and another for the right part of the screen. > > (two "stripes" of 1920x2400). > > > I'm trying to come up with a solution to "transform" one into another, > > without using a frame buffer nor storing more than 1 line of video. > > (At 3840, in color, that already is 6 Xilinx BRAMs and I'm a little > > short of those ...). > > > According to my calculations, It should even be possible to only store > > half a line, but I prefer to have a 1 line delay than half a line > > delay. > > My problem is that I can't find how to do it ... Storing in BRAM has > > proven to be an addressing nightmare to store and reread simultaneously > > without overwriting data I haven't re-read yet ... (since I don't read > > in the same order that I write). > > > Does anyone has done something similar or has a genius idea ? Because > > I'm missing something here, that should be simple and I just don't see > > it ... > > > SylvainArticle: 114759
I don't doubt what you are saying about the memory leaks. However, i have to take in to consideration JAVA, which has no real memory management, and by this i mean you cannot malloc and free memory, rather it relys on the fact that you use the new and delete operators. But even then if it suspects that a block of memory is going to be used it will not let it go. As much as i love Firefox it suffers from the same memory leak issues. About once every 3 or 4 days i have to close out all browsers and free up about 600MB of memory. I also cannot blame Xilinx for using JAVA, as it works on my Linux x86_64 AMD machine (at least i could start the project navagator) with very little fuss. I also agree version 8 was a step backward, it added some new icons, design partitions and a whole bunch of nothing usefull. I have never had the pleasure of using 6.3 in depth, when i got in to CPLD/FPGAs, (early 2000) i used CUPL on an Altera Device, and needless to say it worked very well as a glue logic chip. I think i used Xilinx 6.3 for about one or 2 months before 7.1 appeared and quiclky switched. Right now, i would like to find a good method of using the Xilinx Tools, since I'm using their FPGAs, to conduct long term hardware validations without restarting all the tools about once every 10 builds. Yes, i know that i am probably not doing this 100% right and more simulation could lead to less building but, if i had all the time in the world to complete my projects i would simulate every last aspect including my drive to work to ensure it would not effect my coding style that day, you get what i mean. So, I ask Martin, as he posted a method of using build scripts, if you could even if in part, post some of what you use, that might benefit the community here. I would certainly build on those scripts and post them back. I still have not received a difinitive answer to a key question i had posted, if anyone knows, can you provide some light on the subject. Does Xilinx use it's own canned JRE or does it use the installed JRE? I have just downloaded and installed Java SE Runtime Environment 6 from Sun, maybe it will help maybe not. --Brian On Jan 23, 2:57 pm, "jbnote" <jbn...@gmail.com> wrote: > > Memory leaks come from sloppy programmers. Not fixing memory leaks > > comes from lazy or incompetent programmers.Even incompetent programmers can manage this. The use of valgrind > [http://www.valgrind.org] will pinpoint memory leaks right to the line > where the allocation was made. It runs on unmodified software. This > would be, oh, one hour work maximum if you have the source. > > JBArticle: 114760
Dear all, Thank you for all of your suggestions. Regards, -danielArticle: 114761
Google Subversion. And if you use Windows, Google Tortoise. HTH, Syms. p.s. This chap recommends it on his blog. http://www.cambriandesign.com/Article: 114762
Sylvain,
Speed tip for modular address calculation:
On Jan 23, 3:14 pm, "JustJohn" <john.l.sm...@l-3com.com> wrote:
> On Jan 22, 12:33 am, "Sylvain Munaut <Some...@SomeDomain.com>"
> The approach to solving your addressing dilemma is to start small.
_An_ approach...
> Look at a line that is only 12 pixels long. On your first pass you will
> write to these locations:
> | first half line | second half line |
> 0 1 2 3 4 5 6 7 8 9 10 11
> On your next line, you want to Read before Write these locations:
> 0 6 1 7 2 8 3 9 4 10 5 11
> Continuing this pattern gives:
> 0 3 6 9 1 4 7 10 2 5 8 11
> 0 7 3 10 6 2 9 5 1 8 4 11
> 0 9 7 5 3 1 10 8 6 4 2 11
> 0 10 9 8 7 6 5 4 3 2 1 11
> 0 5 10 4 9 3 8 2 7 1 6 11
> 0 8 5 2 10 7 4 1 9 6 3 11
> 0 4 8 1 5 9 2 6 10 3 7 11
> 0 2 4 6 8 10 1 3 5 7 9 11
> 0 1 2 3 4 5 6 7 8 9 10 11
> and voila, you're back where you started.
>
> Let the magic of modular arithmetic help you.
> Below is a perl script that generates the sequences you need, and shows
> everything you need to do. It takes one accumulator and one counter, an
> addition, a comparison, and optional subtraction. Limit may be
> programmable since you want to handle arbitrary line lengths right?.
> You have not mentioned what clock rate you have, but if you translate
> this into VHDL, you may even be able to get the addition, comparison,
> and optional subtraction into a single cycle. If not, then you can
> double the width of the BRAM inputs/outputs using external registers,
> demuxes/muxes until you have enough time to do the requisite modular
> addition.
I wasn't thinking all the way through in the last two sentences above.
I expressed the modular increment as:
$Addr += $Incr;
$Addr -= $Limit if ( $Addr > $Limit );
Since this is probably very fast stuff (being Hi-Res video), and done
in H/W, you can take a different approach.
Rather than do the addition, then the comparison, then the optional
subtraction, do two versions of the addition in parallel, and a
modified comparison, using that to select between the two results.
( Let A = Addr, I1 = Incr, I2 = Incr - Limit )
I2 is computed sometime after NewIncr is set in the previous line, and
before the current line starts.
The two additions are:
A1 = A + I;
A2 = A + I2;
The original comparison I posted was essentially:
if ( ( A + I ) > L )
This can be reworked by letting C = L - I
Since L and I are fixed for the line duration, C can be computed once
before the line starts.
Using C, the comparison becomes
if ( A > C )
A <= A2
else
A <= A1
The whole circuit operates almost as fast as a simple counter followed
by a mux.
You can extend the concept to operate on both ports of a DP_BRAM, so
that you can retrieve
both first half line pixels and second half line pixels simultaneously.
(Left as an exercise).
HTH
Just John
Article: 114763>Does anyone know if it is possible to permanently harm a Xilinx FPGA >internally through a bad (accidental or malicious) bitstream? about 10 years ago i had a loaded one from a bad eeprom. blew little holes in the package. -- mac the naïfArticle: 114764
Hi: I used to use the Xilinx Constraints Editor (XCE) (right click on the .ucf file under my source file, and open it) in Webpack 5.2i to assign nets to pins for Coolrunner XPLA3 projects. Now I have updated to 8.2i (oh, why!?!?) and I find that when I open a .ucf file with the XCE, that in the ports tab, location column, all are read-only. That is, I can't enter pins here anymore. I have figured out how to use PACE, but I don't like it. I like XCE. Hmm, now I see XCE has this new "Constraints Window" that has a tab: "Source Constraints (read-only)" which lists the pin constraints. Now why did they do that? Is it impossible to use XCE to set pins anymore? Thanks. -- _____________________ Christopher R. Carlen crobc@bogus-remove-me.sbcglobal.net SuSE 9.1 Linux 2.6.5Article: 114765
Ben Jackson wrote: > Drunk is the right state to use iMPACT. For example, if you go back and > forth between writing .bit's into FPGAs and .mcs's into Xilinx config > proms, you will want to stab someone each time you forget to turn ON > erase/verify/use-internal-config-clock for the PROM because iMPACT > mysteriously forgot those settings... AGAIN One of numerous quirks... In ISE8.2 SP3, iMPACT just crashes if you dare to rename or move the bitfile that is currently assigned. And has anyone noticed that it uses two different file selection boxes? If you detect the JTAG-chain and it finds a device, it prompts you automatically to select a corresponding bitfile. The selection box is "old style"; for example you can't enter network paths manually, and the drop-down list for drive selection only shows the drive letters, not the names. So imagine you have 4 or 5 network shares mapped and you just cannot remember if the one the bitfile is on was X:, Y: or Z:... Very annoying. But if you assign a new bitfile later on (e.g. by right-clicking the device and selecting "Assign new bitfile"), you get a completely different file selection box, the standard one more or less all Windows applications use now. So obviously two different people worked on that, two different codes for the same thing. Not a "problem" per se, but it makes you wonder... if things like that are common in other parts of ISE, it might explain certain "This only works when I do it like this but not when I do it like that"-effects. -- My email address is only valid until the end of the month. Go figure what the address is going to be after that...Article: 114766
bgshea wrote: > WOW, thanks everyone for the input. I'm going to dig though this info > and esp. the links provided. > > I would love to see some linux build scripts. I love EMACS!! and use it > for all my c/c++ developement in linux. However, i don't have a PC to > space in my office for linux yet. But i can certainly try on one of my > personal Linux boxes. Xemacs including VHDL mode is available for Windows as well. And you can install Cygwin (http://www.cygwin.com) on any Windows box to get an almost complete UNIX-like environment, with Bash, grep, sed, awk, make, Perl, whatever you need to run build scripts. cu, Sean -- My email address is only valid until the end of the month. Go figure what the address is going to be after that...Article: 114767
Thank you for your time Red.
I was able to access the url and did the following:
- copied the squares code into a brand new vhdl
project created with Xilinx ISE 7.1i
- changed clk50 into clk25 (see below for full vhdl code)
- flipped the clock jumper on Nexys to 25MHz
- assigned pins (see .ucf below)
- Changed "Generate Programming File"
FPGA Start-Up Clock option to JTAG Clock
- Added one timing constraint "25 MHz HIGH 50 %"
to clk25 signal in Xilinx Constraints Editor
- have not touched anything else in the project
- Built the project
- Uploaded it onto Nexys using ExPort
And I'm still getting the scanline jitter on my monitor.
Could you try to run my code (below) on you nexys and
say whether the picture is perfectly stable?
> Doubt your oscillator is bad if you are seeing anything.
> Try a simple divide by 2 or 4 circuit and check the output with your
> scope.
25MHz looks like a 25MHz square wave (it rings just a little bit)
1000ns after-trigger-delayed trace shows "thicker" edges (due to jitter)
> Have you stipulated a constraint of 100MHz input for the mClk
> pin to see if your design can run at that speed?
> 10ns clock period doesn't leave much room to play with.
I've changed my clock to 25MHz and set the timing constraint.
xilinx tools displayed the following:
----------------------------------------------------------------------------
----
Constraint | Requested | Actual |
Logic
| | |
Levels
----------------------------------------------------------------------------
----
TS_clk25 = PERIOD TIMEGRP "clk25" 25 MHz | 40.000ns | 7.366ns | 3
HIGH 50% | | |
----------------------------------------------------------------------------
----
>
> vertical count is not synchronized to the horizontal count.
I tried dependent counters as well... Thanks for noting this though.
============== squares.ucf ==============
NET "clk25" TNM_NET = "clk25";
TIMESPEC "TS_clk25" = PERIOD "clk25" 25 MHz HIGH 50 %;
#PACE: Start of Constraints generated by PACE
#PACE: Start of PACE I/O Pin Assignments
NET "blue_out" LOC = "L15" ;
NET "clk25" LOC = "A8" ;
NET "green_out" LOC = "N15" ;
NET "hs_out" LOC = "R6";
NET "red_out" LOC = "P16" ;
NET "vs_out" LOC = "R7";
#PACE: Start of PACE Area Constraints
#PACE: Start of PACE Prohibit Constraints
#PACE: End of Constraints generated by PACE
============== squares.vhd ==============
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity clockmodule is
port(clk25 : in std_logic;
red_out : out std_logic;
green_out : out std_logic;
blue_out : out std_logic;
hs_out : out std_logic;
vs_out : out std_logic);
end clockmodule;
architecture Behavioral of clockmodule is
signal horizontal_counter : std_logic_vector (9 downto 0);
signal vertical_counter : std_logic_vector (9 downto 0);
begin
process (clk25)
begin
if clk25'event and clk25 = '1' then
if (horizontal_counter >= "0010010000" ) -- 144
and (horizontal_counter < "1100010000" ) -- 784
and (vertical_counter >= "0000100111" ) -- 39
and (vertical_counter < "1000000111" ) -- 519
then
red_out <= horizontal_counter(3)
and vertical_counter(3);
green_out <= horizontal_counter(4)
and vertical_counter(4);
blue_out <= horizontal_counter(5)
and vertical_counter(5);
else
red_out <= '0';
green_out <= '0';
blue_out <= '0';
end if;
if (horizontal_counter > "0000000000" )
and (horizontal_counter < "0001100001" ) -- 96+1
then
hs_out <= '0';
else
hs_out <= '1';
end if;
if (vertical_counter > "0000000000" )
and (vertical_counter < "0000000011" ) -- 2+1
then
vs_out <= '0';
else
vs_out <= '1';
end if;
horizontal_counter <= horizontal_counter+"0000000001";
if (horizontal_counter="1100100000") then
vertical_counter <= vertical_counter+"0000000001";
horizontal_counter <= "0000000000";
end if;
if (vertical_counter="1000001001") then
vertical_counter <= "0000000000";
end if;
end if;
end process;
end Behavioral;
============== end of vhdl ==========
Corer.
From invalid@dont.spam Tue Jan 23 22:42:36 2007
Path: newssvr13.news.prodigy.net!newsdbm04.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newshub.sdsu.edu!nx02.iad01.newshosting.com!newshosting.com!130.81.64.211.MISMATCH!cycny01.gnilink.net!spamkiller2.gnilink.net!gnilink.net!trndny05.POSTED!933f7776!not-for-mail
From: Phil Hays <invalid@dont.spam>
Subject: Re: Xilinx ISE 8.2
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table)
Message-Id: <pan.2007.01.24.06.45.49.874398@dont.spam>
Newsgroups: comp.arch.fpga
References: <1169489849.344862.112520@51g2000cwl.googlegroups.com> <ep5es2$vv2@cnn.xsj.xilinx.com> <12rcrgff947a4e5@corp.supernews.com> <1169589412.427666.58670@k78g2000cwa.googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Lines: 30
Date: Wed, 24 Jan 2007 06:42:36 GMT
NNTP-Posting-Host: 71.112.133.239
X-Complaints-To: abuse@verizon.net
X-Trace: trndny05 1169620956 71.112.133.239 (Wed, 24 Jan 2007 01:42:36 EST)
NNTP-Posting-Date: Wed, 24 Jan 2007 01:42:36 EST
Xref: prodigy.net comp.arch.fpga:125992
bgshea wrote:
> ISE has been, IMHO, going down hill. With each new release the projects
> become backward incompatible.
Perhaps you should try script based builds such Tcl or makefiles, and use
a source control program such as SVN.
Tcl or "tool control language" is a industry standard language. Documented
Tcl was new with 8.2, and in my never humble opinion was a big step
forward. I've taken a design I'm working on between 8.2 and 9.1 and back
again several times without changing the Tcl script. Nice section on Tcl
in the manual.
A source control program will allow you to have access to any past
revision of your code, to show the differences between each revision,
allow changes to be reverted (or backed out). It also makes it easier to
work on multiple machines, or for multiple people to work on the same
design.
http://subversion.tigris.org/
As you like emacs, you might also like this:
http://www.xsteve.at/prg/vc_svn/index.html
--
Phil Hays (Xilinx, but always speaking for myself)
Article: 114768doug wrote: > ISE has been an experience. By version 6.3 it was reasonably > good. It did what I wanted and did not cause too much trouble. > Version 7 was a huge step backwards. Project navigator got user > surly and very slow. Whoever did the design never used it for > anything. Version 8 reached a new low. The stupid design to > change the project files, later partly removed, made for lots of > headaches. I think the main problem is that Xilinx releases new ISE versions in a predefined schedule, as Austin mentioned in Antti's thread about non-volatile Xilinx-FPGAs. A new ISE release comes out regularly, not when it's done. But on the other hand, it doesn't make sense to release a new version, when there's nothing new in it. The marketing department has to brag about it being another 30% faster than the previous release, having gazillions of new features, and so on. This approach results in the software department always being busy integrating new features so they can make the fixed deadline for the new software release, resulting in software that's usually not usable until three service packs later, and just when it finally *IS* usable, support is dropped because the next release comes out and it all starts over again. Sometimes you get the idea that a new ISE is not just a new software version, but an entirely new product. Maybe it was just quicker to start from scratch than to fix what was already there. And then you get effects like bugs that were fixed in 7.1 re-appearing in 8.1 and things like that... We had a Xilinx FAE here in late November, introducing us to Virtex-5, and when the topic of bugs in ISE came up, he actually said that we needn't bother sending in bug reports now, since the entire software department at Xilinx was now scrambling to make the deadline for the 9.1 release and nothing would really happen until after that anyway. And bug reports for ISE8.2 were useless anyway, since all the work is going into 9.1 now... Add to this the additional support for Linux (which wasn't there before 6.3, I believe, and which I highly appreciate, BTW), and you get a situation where even competent programmers can't produce decent software, IMHO. What is it with that regular release cycle? Does any other FPGA manufacturer do this? Or any other software company? What good is it? Customers have licenses, that are valid for one year, so you have to pop out one release a year so they get something for their money or what? I don't really get it. Software-quality-wise it does not make sense at all IMHO. And then things like Antti mentioned happen: ISE9.1 is out, and it has support for devices that aren't even announced yet, i.e. no small customer is going to get for another year anyway. Why not just fix some bugs instead of integrating phantom devices? Why not just fix what's broken instead of adding even more new stuff that's broken as well? Partial reconfiguration is another example. I've been fiddling around with this since ISE4, gave up with ISE7, since I always ran into some "FATAL_ERROR"-thingies that "will be fixed in the next service pack" or "will be fixed in the next ISE release", but never were. Now with software radio being a high-volume-application, they seem to have fixed it, but only in specially patched ISE8-versions you have to get through your FAE. And does anyone besides me think that it's ridiculous to release the first service pack only days after the software? Doesn't that in itself tell you that obviously the software wasn't ready to be released in the first place? Service pack sizes of > 300MB, where basically every single file in the installation is replaced, aren't a good sign either. -- My email address is only valid until the end of the month. Go figure what the address is going to be after that...Article: 114769
On 2007-01-24, Sean Durkin <news_jan07@durkin.de> wrote: > One of numerous quirks... In ISE8.2 SP3, iMPACT just crashes if you dare > to rename or move the bitfile that is currently assigned. That's probably related to the fact that you can't assign a new one. The menu option is there, and if you select it you get the bit/bmm/etc dialog, but if you select the old .bit file, "remove" stays grayed out. I end up rediscovering the chain to have another go at assigning a file. Since it doesn't really remember my settings for the prom or cpld anyway it hardly matters... And considering the tool can't remember settings WHILE it's running, why is it so rabid about having you work within an open "project" which it wants to save for you? -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 114770
Since nobody wants to answer... I don't have any practical experience with sysgen, but here is what I know: 1. It seems that Xilinx uses sysgen internally to develop their new cores. As a result some of the newer cores are not available through coregen, but only through sysgen or through a special request for a netlist. For example, take a look at their DUC core or at the Continuously Variable Fractional Rate Decimator described in the appnote XAPP936. 2. Sysgen in concert with MATLAB Simulink seems to be a nice tool helping to visualize what happens with the signal. However I am not at all sure this tool won't be an annoying extra layer of complexity when designing low level interfaces between the modules. 3. Sysgen + Simulink cost a lot of money. /Mikhail <nbg2006@gmail.com> wrote in message news:1169404354.471231.198040@s34g2000cwa.googlegroups.com... > Hello all, > I just wanted to find out how good system generator software is? I can > program in VHDL and would like to know if the SYS gen software would > make life easier for me when it comes to designing DSP filters , FFTS > or other DSP blocks. > Does Xilinx provide IPs separately for the DSP blocks? If so then How > different is it from using Xilinx IP in the design instead of sysgen > blocks ? > Any experience on system generator software would be helpful . > Thanks, > nbg >Article: 114771
pbFJKD@ludd.invalid wrote: >>>>> Now all you need is a Gerber-driven solder paste dot printer! They >>>>> exist, and news of an affordable unit for prototyping would be interesting. >>>> Following up myself, the Essemtec CDS6700 solder paste printer seems to >>>> cost around $25,000. Not quite affordable ;-) >>> Makes me wonder what it would cost to build x-y table and reuse a inkjet >>> cartridge ;) > >> Maybe with a DVD inkjet printer (like Epson R200), should hold a Eurocard 100x160. >> DVD is 120mm wide, it is in a tray that slides through the printer, no length limit. >> Costs 80 Euro to try... > > Do you think the solderpaste would get through the ink channels ..? > Maybe it's viscosity is too high. > > I also think that any ordinary underpriced inkjet will be just fine. Just > bring the screwdriver. On a more serious side, increasing the distance > between printheads and printer bottom. Then add some wagon to fasten the > pcb into which is driven by the paperfeed mechanism. > > I think the real blocker is the ink channel mechanism, once that is solved it > depend mainly on precision of x-y table + diameter of the solderpaste drop. > 5-10 mil should be enough precision on the maximum side? > How about an old scanner, turned upside down, with the optics replaced by a paste syringe, pumped by either a stepper motor & leadscrew, or by something generating pulses of air pressure (which is how the professional rework stations do it)?Article: 114772
doug wrote: > Memory leaks come from sloppy programmers. Not fixing memory leaks > comes from lazy or incompetent programmers. It is clear that the > programmers did not test their code. They seem to think that "testing" > means looking to see if it blows up in the first ten seconds. This is Actually, memory leaks are just another bug, like any other, better programmers will have fewer of them than worse/sloppy programmers. There will be bugs. Testing is QA's responsibility. The decision to fix things is up to project management. The fault of ISE rather clunky behavior and problems - I'm a newbie here, been using it for a few days and 600 lines of VHDL - can be laid at the feet of middle managment at Xilinx. If one feels insulted and frustrated that Xilinx doesn't believe it is worth it to prioritize fixing longstanding issues, then you have to vote with your qty 10,000 design decisions. It is the only thing that makes businesspeople really listen. I've seen some of the problems mentioned here already. Process "_pn" hanging around. Multi-second lag times to start tools. Weird project setting problems in iMpact or whatever it is called (fortunately I just use it to make a hex file I process with a script to make a const array in C for the microcontroller code). Somewhat disappointing but so far no synthesis bugs. To ISE's credit, having error messages have a link to knowledgebase articles on xilinx.com has been very handy. Smart. JArticle: 114773
Wow, that's cool. JBArticle: 114774
>> I think the real blocker is the ink channel mechanism, once that is solved it >> depend mainly on precision of x-y table + diameter of the solderpaste drop. >> 5-10 mil should be enough precision on the maximum side? >> >How about an old scanner, turned upside down, with the optics replaced >by a paste syringe, pumped by either a stepper motor & leadscrew, or by >something generating pulses of air pressure (which is how the >professional rework stations do it)? Add a printer "x-drive" to the scanner and the x-y is complete. Syringe pumped with leadscrew might work, albeit possible slow. The air pressure approach together with a magnetic valve may also work. What do you think about a combined camera + very thin soldering iron to completly rid of the oven stage..?
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