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
jg, If the part is hot socket capable (can plug in with power ON all IOs), then the IO structure can't use the foundry self protecting IOs, and has to use other tricks to meet ESD spec, and work. Back to back diodes are pretty common. As for seeing this sort of data in the spec sheet: I already said it will not appear, as it is not a supported "use" (there is no standard that requires it, and full support of any swing and common mode voltage is crazy -- there would be a delay table for every Vcm and every swing). If all you want is a reasonable comparator (which is basically faster than any off the shelf comparator by a factor of hundreds to thousands), it is there. Austin Jim Granville wrote: > nospam wrote: > >> Some time ago I did some experimentation (for a very cost sensitive >> application) with a Spartan 3 part using an LVDS differential input as a >> voltage comparator for a crude delta sigma ADC. >> The I/O bank Vcco was 3.3v the common mode on the LVDS inputs was half >> the >> 3.3v supply and the differential input voltage was (obviously) limited to >> whatever it took drive the LVDS input one way or the other. >> It worked fine. >> Now the customer says he wants to use Cyclone II. >> I want to run the I/O bank on 3.3v and for Cyclone II I don't want to >> have >> to provide a 2.5v supply just for this one input. >> So I ask an Altera FAE can I run an LVDS (as a crude voltage comparator) >> input on 3.3v biased at 1.65v. >> After an age I get the answer no, but I could use an LVPECL standard >> <sigh>. Even from the very skimpy Altera data I can tell that 1.65v is >> outside the LVPECL standard common mode range and LVPECL is only >> available >> on dedicated clock input pins anyway. >> So I ask the question again and after another age get told no, LVDS >> has to >> run on 2.5v and no more than 650mV differential input with no further >> explanation. > > > When someone says that, it starts to sniff of a back-back clamp diode > structure - some opamps do use this to protect sensistive 1st stage > devices. Would be surprising on a FPGA tho. > > This is the sort of thing you could test on a bench very easily ? > > -jg >Article: 101701
Quartus provides a way to generate one compressed archived with all the
required files. To archive, go to your project directory type:
quartus_sh --archive <revision name>
This command will generate a <revision name>.qar file. To unarchive type
quartus_sh --restore <revision_name>
As part of the --archive, a <revision name>.qarlog which lists all archived
files. You can parse this list to determine which files are most important,
but note the list will also contain reports and other important output files
(which many times are also put under revision control). To capture the
sopc_builder files, add all files which end with the ptf extension to this
file list. This may already be there in the qarlog file but do verify it for
completeness.
As mentioned in my earlier post you can access the "Source Files Read" or
any other report panel via Tcl. Use "quartus_sh --qhelp" to get details.
Look for the "report" package. Here is the script that you will need (run
it after you have compiled your project so that the report is available):
"myscript.tcl"
load_package report
set revision name [lindex $quartus(args) 0]
project_open $revision_name
load_report
# Set panel name and id
set panel "*Source Files Read"
set id [get_report_panel_id $panel]
# Get the number of rows
set row_cnt [get_number_of_rows -id $id]for {set i 0} {$i < $row_cnt} {incr
i} {
puts [get_report_panel_data -row $i -col_name "*Absolute Path" -id $id]
}
unload_report
project_close
To execute this script type
quartus_sh -t myscript.tcl <revision name>
You should be in your project directory when you execute this.
Hope this helps,
Subroto Datta
Altera Corp.
"avishay" <avishorp@yahoo.com> wrote in message
news:1146742752.281482.145790@y43g2000cwc.googlegroups.com...
>I see that this thread creates lots of interest, but it has gone a
> little off topic.
>
> I will try to describe the problem I face in more details. The grup I
> work in is composed of several hardware (FPGA) engineers. Some of them
> use VHDL, and some use graphic methods. Currently, no source control of
> any kind is used, making tracking design sources and sharing them among
> the group very difficult. In order to solve some of these problems, I
> want to install and start use Subversion as a source control system.
> What I look for is a way to automatically include in the source control
> components that are normally added in the graphic editor or using the
> MegaWizard interface. Another, related problem is taking an existing
> Quartus project, and putting it under source control without losing
> files and without including files that are not necessary. The best way
> to accomplish both tasks, in my opinion, is writing a script that wolud
> go through the project hierarchy (after synthesis), pick up all the
> source files used and add them to the source control system (if theyr'e
> not already there).
> Subroto Datta suggested to use the "Source Files Read" section of the
> analysis report, which seem to be a good direction, but I need to know
> if there is a way to get this information*programatically*, rather than
> text processing the report. This report also seem to lack memory
> initialization files (maybe more kind of files I don't know of?).
>
> Another type of problem is the SOPC builder. The SOPC builder takes the
> system specification from PTF files (as KJ mentioned) and copies HDL
> files from the relevant library into the project directory. These
> copied files are not strictly sources, but rather intermediate
> products, and as such they should not be under the soruce control (they
> should, in fact, but they should be controlled by the one that wrote
> the component, not the one using them). After SOPC builder has finished
> its run, there is no way (to my understanding) to distinguish between
> true source files and those who were copied. They will both show up the
> same in the said report. A possible solution might be to instruct SOPC
> builder to copy its files to a directory other than the project root (I
> think it would be much easier to manage also), but I don't know how to
> do that.
>
> Thanks for everyone who has replied (and will)
> Avishay
>
Article: 101702Hi Ray, It is really a marvelous invention!!! Who is the inventor? WengArticle: 101703
Austin Lesea <austin@xilinx.com> wrote: >It is powered from Vccaux, not Vcco! Thanks for the insight. On the Spartan 3 initially I just ran the I/O bank on 3.3v without worrying about it and it seemed to work. If the Spartan 3 data sheets says what the differential inputs are powered from I must have missed it. The I/O pin schematic does show what Vcco is used for. I kinda guessed the inputs ran from Vccaux although needing a Vccaux supply is a minus point for the Spartan. >Since Vccaux is 2.5 volts in Spartan 3, that means that an input voltage >has to be in the range of 0 to 2.5 volts just to work at all (common >mode range). From memory the Cyclone II LVDS inputs have a similar common mode range so if they really run from a 1.2v Vccint they must have a different configuration and probably worse performance as a general purpose comparator. Guess I'm going to have to experiment. --Article: 101704
Jim Granville <no.spam@designtools.co.nz> wrote: >> So I ask the question again and after another age get told no, LVDS has to >> run on 2.5v and no more than 650mV differential input with no further >> explanation. > When someone says that, it starts to sniff of a back-back clamp diode >structure - some opamps do use this to protect sensistive 1st stage >devices. Would be surprising on a FPGA tho. > This is the sort of thing you could test on a bench very easily ? It wouldn't matter to me the converter keeps the comparator 1 'bit' either side of it's switching point anyway. Input offset and hysteresis will mess up the converter some, but I only need 'crude'. When I was experimenting it was digitising an ac signal so I couldn't easily make measurements. When I get back to it I will do some dc testing and discover more about the comparator. --Article: 101705
Austin Lesea wrote: > jg, > > If the part is hot socket capable (can plug in with power ON all IOs), > then the IO structure can't use the foundry self protecting IOs, and has > to use other tricks to meet ESD spec, and work. Back to back diodes are > pretty common. In FPGAs ? Can you give an example ? > > As for seeing this sort of data in the spec sheet: I already said it > will not appear, as it is not a supported "use" (there is no standard > that requires it, and full support of any swing and common mode voltage > is crazy -- there would be a delay table for every Vcm and every swing). > > If all you want is a reasonable comparator (which is basically faster > than any off the shelf comparator by a factor of hundreds to thousands), > it is there. Other vendors data sheets have items called 'Guaranteed by design' and 'not tested' - it tells designers what the limits of the device are. This proves one _can_ publish usefull design info, and not have to add any testing load to your flows. (which seems to be your aversion ? ) A LVDS cell is either rail-rail by design, or it is not. ( the good ones are... ) -jgArticle: 101706
Is there information on how to use a user IP that is attached to the OPB with different clock speeds? I currently have the IP core wrapped in the default Import Peripheral Wizard files. The user_logic is Verilog. The custom IP is instantiated in the user_logic. Different bits of several slave registers are conected to the core. MicroBlaze code "talks" to the slave registers by using the customary addressing is C code. There is one trigger bit that starts the user IP. Once the functionlaity of the IP is done, it asserts a flag that is routed back to the user_logic level. I added an "else if" statement to the default slave register model implementation in the user_logic. The default implemetation has two states. The first is "if ( Bus2IP_Reset == 1 )", the other is the "else" and assigns the slave registers based on the "slv_reg_write_select" signal. I inserted an "else if" before the aforementioned "else". It goes: "else if (done_flag_i)", and assigns to slave register 2. It "clears" the bit that initially triggered the module. The embedded code waits in a while loop until the bit is cleared. This has worked GREAT (no problems!) while the exact same clock is connected to both the OPB clock and the user IP's clock. We are trying some things with clocking. If we connect the OPB clock of this core to the common clock that attaches to all other OPB clocks and the uBlaze, and then we connect another DCM-derived clock to the user IP core clock, the behavior is hit or miss. We have tried different clock speeds. One experiment was to use the two different clocks, but at the same speed. Again, this doesn't work consistently. There are definitely the facts that the two clocks are not EXACTLY the same speed, and there is no phase certainty between the two clocks. I am thinking that we either need to implement clock domain crossing sync logic on each signal that passes between the user_logic and the IP core we instantiate or that we need to take advantage of the handshaking signals of the OPB...like the ack signal. However, I can't seem to find any examples of how to do this -- the handshaking that is. I know how to implement the sync flops. The opb_ipif_pdf vs 3.04a document has info, but appears to not have any figures (timing diagrams) where it is supposed to. Maybe mine is screwed up! Any advice would be appreciated!!Article: 101707
> You should let the customer know who is likely to provide you with more > timely and useful information. They might change their mind.... It depends where you are. Both companies have good and not so good FAE's. But I believe it to be very important for a company to have good FAE's; because sometimes it is the deciding factor as to which device an engineer will pick. "Austin Lesea" <austin@xilinx.com> wrote in message news:e3dudj$cvm12@xco-news.xilinx.com... > nospam, > > The LVDS input buffer in VII, II Pro, V4, Spartan 3, and 3E is a full CMOS > differential comparator, than will 'function' from rail to rail. > > Basically, each input ties to both a nmos differential pair, AND a pmos > differential pair, so that even when one, or the other is cutoff (out of > its range), its complement is still in range, and will operate to sense > the difference properly. > > Why did we go tothis extra trouble? Well, these are tiny devices, and it > basically costs nothing to do it right the first time, so that you could > meet or beat any standard that anyone dreams up without redesigning it. > > It is powered from Vccaux, not Vcco! > > Since Vccaux is 2.5 volts in Spartan 3, that means that an input voltage > has to be in the range of 0 to 2.5 volts just to work at all (common mode > range). We don't specify it use at the rails, because we can't > cahracterize all the possible uses of the circuit. For low speeds, as I > said, it will function. Don't complain if it doesn't switch as fast as it > is specified for the LVDS specification (you are not using it there). > > Since every IO pin also has a giant nmos and pmos stack for the single > ended driver attached to it, you also have a diode from ground to the > pins, and a diode to Vcco for the bank. That means if the pin voltage > tries to go below ground (negative ~ 0.5V or greater) or above Vcco > (~Vcco+~0.5V) you will clamp the pin to that one diode above or below > ground. > > You should let the customer know who is likely to provide you with more > timely and useful information. They might change their mind.... > > Austin > > nospam wrote: > >> Some time ago I did some experimentation (for a very cost sensitive >> application) with a Spartan 3 part using an LVDS differential input as a >> voltage comparator for a crude delta sigma ADC. The I/O bank Vcco was >> 3.3v the common mode on the LVDS inputs was half the >> 3.3v supply and the differential input voltage was (obviously) limited to >> whatever it took drive the LVDS input one way or the other. It worked >> fine. Now the customer says he wants to use Cyclone II. I want to run the >> I/O bank on 3.3v and for Cyclone II I don't want to have >> to provide a 2.5v supply just for this one input. So I ask an Altera FAE >> can I run an LVDS (as a crude voltage comparator) >> input on 3.3v biased at 1.65v. After an age I get the answer no, but I >> could use an LVPECL standard >> <sigh>. Even from the very skimpy Altera data I can tell that 1.65v is >> outside the LVPECL standard common mode range and LVPECL is only >> available >> on dedicated clock input pins anyway. So I ask the question again and >> after another age get told no, LVDS has to >> run on 2.5v and no more than 650mV differential input with no further >> explanation. I just read through the Cyclone II Device Handbook again and >> find it says "Cyclone II devices have one set of VCC pins (VCCINT) that >> power the >> internal device logic array and input buffers that use the LVPECL, LVDS, >> HSTL, or SSTL I/O standards." >> >> So if I believe this the Vccio supply is irrelevant for LVDS receivers >> and >> the FAE was talking crap again. Can anyone confirm this and has anyone >> experience of using LVDS inputs as >> voltage comparators on Cyclone II (or Spartan 3/3e for that matter). --Article: 101708
I did a design with a Cyclone (not CycloneII) where I received LVDS at 267Mbps while Vccio was powered with 3.3V. It wasn't clear in the data sheet but I surmised it was possible from one of the Quartus reports. So I checked with my FAE and he said it is possible to run the receivers at 3.3V, but not the transmitters. I've never used the CycloneII, but perhaps it is similar in this regard??? "nospam" <nospam@please.invalid> wrote in message news:b5ok52dufbephvq2d8l6396gr2tqo8vjda@4ax.com... > > Some time ago I did some experimentation (for a very cost sensitive > application) with a Spartan 3 part using an LVDS differential input as a > voltage comparator for a crude delta sigma ADC. > > The I/O bank Vcco was 3.3v the common mode on the LVDS inputs was half the > 3.3v supply and the differential input voltage was (obviously) limited to > whatever it took drive the LVDS input one way or the other. > > It worked fine. > > Now the customer says he wants to use Cyclone II. > > I want to run the I/O bank on 3.3v and for Cyclone II I don't want to have > to provide a 2.5v supply just for this one input. > > So I ask an Altera FAE can I run an LVDS (as a crude voltage comparator) > input on 3.3v biased at 1.65v. > > After an age I get the answer no, but I could use an LVPECL standard > <sigh>. Even from the very skimpy Altera data I can tell that 1.65v is > outside the LVPECL standard common mode range and LVPECL is only available > on dedicated clock input pins anyway. > > So I ask the question again and after another age get told no, LVDS has to > run on 2.5v and no more than 650mV differential input with no further > explanation. > > I just read through the Cyclone II Device Handbook again and find it says > > "Cyclone II devices have one set of VCC pins (VCCINT) that power the > internal device logic array and input buffers that use the LVPECL, LVDS, > HSTL, or SSTL I/O standards." > > So if I believe this the Vccio supply is irrelevant for LVDS receivers and > the FAE was talking crap again. > > Can anyone confirm this and has anyone experience of using LVDS inputs as > voltage comparators on Cyclone II (or Spartan 3/3e for that matter). > > --Article: 101709
"Austin Lesea" <austin@xilinx.com> wrote in message news:e3dudj$cvm12@xco-news.xilinx.com... > nospam, > > The LVDS input buffer in VII, II Pro, V4, Spartan 3, and 3E is a full CMOS > differential comparator, than will 'function' from rail to rail. > > Basically, each input ties to both a nmos differential pair, AND a pmos > differential pair, so that even when one, or the other is cutoff (out of > its range), its complement is still in range, and will operate to sense > the difference properly. > > Why did we go tothis extra trouble? Well, these are tiny devices, and it > basically costs nothing to do it right the first time, so that you could > meet or beat any standard that anyone dreams up without redesigning it. > > It is powered from Vccaux, not Vcco! > > Since Vccaux is 2.5 volts in Spartan 3, that means that an input voltage > has to be in the range of 0 to 2.5 volts just to work at all (common mode > range). We don't specify it use at the rails, because we can't > cahracterize all the possible uses of the circuit. For low speeds, as I > said, it will function. Don't complain if it doesn't switch as fast as it > is specified for the LVDS specification (you are not using it there). > [snip] Austin, Are you saying that, since in V2-V4 the LVDS input buffer is driven from VCCAUX, even if a bank's VCCO is not 2.5V you may instantiate an LVDS25 input? What about an LVDS output in a non-2.5V VCCO bank? Thanks much, BobArticle: 101710
Weng Tianxiang wrote: > It is really a marvelous invention!!! > > Who is the inventor? No telling. The idea might be uncovered just by observation. When in Berlin the big TV Tower was opened a lot of small gardens where nearby. All of them did not have electric power supply - but at night one could see light bulbs there. They drew energy from the field with a cable - a "long antenna". Nicola Tesla wanted to transport energy by via a radio field. He constructed his famous "Tesla Coil" witch transformed AC to ultra-high voltage (with almost no current). I have seen a Tesla coil producing light strike of over 50cm length - more than 50kV. I touched this strike (with a screw driver to avoid to burn my hand) and felt a small prickle in my lower arm. With this Tesla Coil it was possible to carry a Neon Lamp that was glowing (no wires). And this was the idea of Tesla: He wanted to transport the energy by air. 13,5MHz RFID tags operate with inductive coupling. Therefore the observer of the inductivity could be named as the inventor. -> Joseph Henry, Michael Faraday. 900MHz RFID operate with resonant coupling - the idea of a radio. Marconi could be named as inventor. Ok - this was the direction from the interrogator to the tag. Backward communication is done by drawing more or less energy from the field (switching on/off a load). Who could be named here? - I don't know. RalfArticle: 101711
<tomstdenis@gmail.com> wrote:
+---------------
| What this does open the door for though is for mixed architecture
| systems. E.g. synthesize a MIPS core in the FPGA and map the DDR
| controller on to it.
|
| Then you have x86 and MIPS in the same system.
+---------------
But *not* necessarily running ccNUMA with each other!! See my recent
post on "comp.lang.lisp" [yeah, they were talking about the prospects
for using the same DRC FPGA for an update on the Lisp Machine]:
http://groups.google.com/group/comp.lang.lisp/msg/ac1488796602931d
especially the bits about the difference between "non-coherent HT",
used for ordinary I/O (PIOs & DMA), and the "coherent HT" used for
the inter-Opteron ccNUMA cache-coherency. I *strongly* suspect the
DRC FPGA[1] only does non-coherent HT, which, while just fine for
a DMA-style crypto co-processor, wouldn't let your FPGA-based MIPS
CPU participate in the Opteron cache-coherency protocol.
-Rob
[1] Well, the *chip* could probably do either; I'm actually referring
to whatever libraries of HT protocol support that come with it.
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Article: 101712Hi all, I'm using XUPV2P xilinx board. In that audio codec chip for AC97 support is avaliable. I plan to use linux-2.4.26 as RTOS. Now there are linux BSP availble from xilinx for ps/2, ethernet, systemACE Flash etc. But there is no linux BSP available for AC97 Audio codec chip LM4550. But general AC97 codec drivers, I could see in linux distributions. How can I modify the general driver to be xilinx board specific BSP. so that after libgen I'll copy this drivers into kernel and cross compile it. Regards PrakashArticle: 101713
> You must distinguish between the relatively long time that th DLL takes > to achieve lock (many microseconds) and the very small phase error on > the outputs (picoseconds, which is million times shorter) once the DLL > is locked > > So, the different DLL will most likely achieve lock at different times, > but once in lock, they will each perform to data sheet specs, which > means picoseconds of difference on the outputs Hi Peter, I would have thought that if all DCMs start attempting lock at exactly the same time then they would achieve it at the same time. What causes them to achieve lock at differnt times assuming the input to each is exactly in phase and they start working at the same time? Is it down to differences between the silicon or some other inherent property of the DCMs loop structures? Many thanks, DaveArticle: 101714
Dave wrote: >>You must distinguish between the relatively long time that th DLL takes >>to achieve lock (many microseconds) and the very small phase error on >>the outputs (picoseconds, which is million times shorter) once the DLL >>is locked >> >>So, the different DLL will most likely achieve lock at different times, >>but once in lock, they will each perform to data sheet specs, which >>means picoseconds of difference on the outputs > > > Hi Peter, > > I would have thought that if all DCMs start attempting lock at exactly > the same time then they would achieve it at the same time. What causes > them to achieve lock at differnt times assuming the input to each is > exactly in phase and they start working at the same time? Is it down > to differences between the silicon or some other inherent property of > the DCMs loop structures? Even if the silicon was identical to the Angstroem, you couldn't guarantee they have the same temperature nor that they see the same supply voltage with the same impedance. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 101715
Dear all, I am configuring a Xilinx Spartan 3 using SelectMap (the parallel interface), although the simple details of this interface that I am interested apply to a number of other chips. Having looked at as many datasheets, application notes and examples as I can find, I cannot answer a simple question: in what order are the bytes of a SelectMap configuration stream sent? Ignoring bit-swapping within a byte, are the bytes forming the beginning of the stream (dummy word/sync word) sent as: 0xFF 0xFF 0xFF 0xFF 0xAA 0x99 0x55 0x66 i.e. big-endian, or are they sent as 0xFF 0xFF 0xFF 0xFF 0x66 0x55 0x99 0xAA i.e. little-endian? Any help would be greatly appreciated. TIA, PeterArticle: 101716
sent as aa 55 66 99 AnttiArticle: 101717
Antti wrote: > sent as aa 55 66 99 > > Antti > Thanks for your response, but I'm a little confused. The data sheet specifies the sync dword as 0xAA995566, does that *really* get sent as AA 55 66 99? i.e. byte0 byte2 byte3 byte1? Or did you just mean to point out that the 0xAA is sent first, i.e. AA 99 55 66? If the AA is sent first this makes things a little more tricky for me, as part of a reconfiguration stream passes through my device and I must calculate a CRC. The CRC is calculated least significant bit first which means I must wait for a whole dword before being able to update my current CRC, rather than being able to update it on every byte. This seems most inefficient. Best, PeterArticle: 101718
Peter, the spartan3 select map IF is 8 bit wide, as Antti said before, just send the bytes as they are coming from the *.bit file, 0xFF 0xFF 0xaa 0x55 0x66 0x99 and so on... about the CRC I'm not sure why you would want to calculate the CRC yourself, bitgen does this for you Aurash Peter Mendham wrote: > Antti wrote: > >> sent as aa 55 66 99 >> >> Antti >> > Thanks for your response, but I'm a little confused. The data sheet > specifies the sync dword as 0xAA995566, does that *really* get sent as > AA 55 66 99? i.e. byte0 byte2 byte3 byte1? Or did you just mean to > point out that the 0xAA is sent first, i.e. AA 99 55 66? > > If the AA is sent first this makes things a little more tricky for me, > as part of a reconfiguration stream passes through my device and I must > calculate a CRC. The CRC is calculated least significant bit first > which means I must wait for a whole dword before being able to update my > current CRC, rather than being able to update it on every byte. This > seems most inefficient. > > Best, > > PeterArticle: 101719
Guru Prasad <guruprasad@rassit.com> wrote: >Hello, >I am verry new to this Field and i would be verry happy if anybody would sujjest me a link or any document which gives me an idea on what an FPGA/CPLD is and its arcitecture,how a vhdl code is actually implmented in these... Regards, Guru Prasad http://en.wikipedia.org/wiki/FPGA http://www.fpga4fun.com/ Other than that (simplified) it's a chip that can react to any digital input and send any digital output according to your programming. FPGA - Programming loaded at every startup. Fast & Big. CPLD - Retains programming but have less capacity. (hope I got it right :)Article: 101720
Peter, One more thing, can you please point me to the document and page # where you find 0xAA995566 as sync word? thanks, Aurash Aurelian Lazarut wrote: > Peter, > the spartan3 select map IF is 8 bit wide, as Antti said before, just > send the bytes as they are coming from the *.bit file, 0xFF 0xFF 0xaa > 0x55 0x66 0x99 and so on... > about the CRC I'm not sure why you would want to calculate the CRC > yourself, bitgen does this for you > > Aurash > > Peter Mendham wrote: > >> Antti wrote: >> >>> sent as aa 55 66 99 >>> >>> Antti >>> >> Thanks for your response, but I'm a little confused. The data sheet >> specifies the sync dword as 0xAA995566, does that *really* get sent as >> AA 55 66 99? i.e. byte0 byte2 byte3 byte1? Or did you just mean to >> point out that the 0xAA is sent first, i.e. AA 99 55 66? >> >> If the AA is sent first this makes things a little more tricky for me, >> as part of a reconfiguration stream passes through my device and I >> must calculate a CRC. The CRC is calculated least significant bit >> first which means I must wait for a whole dword before being able to >> update my current CRC, rather than being able to update it on every >> byte. This seems most inefficient. >> >> Best, >> >> PeterArticle: 101721
Mike Treseler wrote:
> Jan Decaluwe wrote:
>
>> I have added a page about a Cordic-based Sine Computer to
>> the MyHDL CookBook:
>>
>> http://myhdl.jandecaluwe.com/doku.php/cookbook:sinecomp
>
>
> Wow. A non-trivial example that works.
> Beautiful generated code.
> (Ignore the synthesis warnings, I think Jan has it right.)
Does Quartus issue warnings also?
No doubt the warnings are related to the use of blocking
assignments in a clocked always block. You know :-)
At least XST doesn't declare this an error. My worst nightmare
would be that half-baked synthesis tools or Verilog gurus
would prevent me from writing code like this. It's a realistic
possibility that explains my occasional angry outbursts.
What I think happens is that XST creates a FF for any reg
in the code. When it detects that the Q output is not used,
it issues a warning. Fine with me, as long as it uses
the D input wire properly :-)
An interesting side effect is that no warnings are issued
in the more "advanced" case when a reg is potentially
used immediately but also stored for later usage,
like the 'counting' flag in this example:
http://myhdl.jandecaluwe.com/doku.php/cookbook:stopwatch
Best regards,
Jan
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com
Article: 101722Hi Peter, AFSIK the syncword is not included in the bitstream CRC calculation. Only the commands and data sections are included in calculation. Regards Jens Aurelian Lazarut schrieb: > Peter, > the spartan3 select map IF is 8 bit wide, as Antti said before, just > send the bytes as they are coming from the *.bit file, 0xFF 0xFF 0xaa > 0x55 0x66 0x99 and so on... > about the CRC I'm not sure why you would want to calculate the CRC > yourself, bitgen does this for you > > Aurash > > Peter Mendham wrote: > > Antti wrote: > > > >> sent as aa 55 66 99 > >> > >> Antti > >> > > Thanks for your response, but I'm a little confused. The data sheet > > specifies the sync dword as 0xAA995566, does that *really* get sent as > > AA 55 66 99? i.e. byte0 byte2 byte3 byte1? Or did you just mean to > > point out that the 0xAA is sent first, i.e. AA 99 55 66? > > > > If the AA is sent first this makes things a little more tricky for me, > > as part of a reconfiguration stream passes through my device and I must > > calculate a CRC. The CRC is calculated least significant bit first > > which means I must wait for a whole dword before being able to update my > > current CRC, rather than being able to update it on every byte. This > > seems most inefficient. > > > > Best, > > > > PeterArticle: 101723
"Austin Lesea" <austin@xilinx.com> wrote in message news:e3e8sb$cuh15@xco-news.xilinx.com... > > As for seeing this sort of data in the spec sheet: I already said it will > not appear, as it is not a supported "use" (there is no standard that > requires it, and full support of any swing and common mode voltage is > crazy -- there would be a delay table for every Vcm and every swing). > > If all you want is a reasonable comparator (which is basically faster than > any off the shelf comparator by a factor of hundreds to thousands), it is > there. > > Austin > Hi Austin, I agree. It's also clear why this behaviour isn't published. I for one am impressed with the performance and flexibility of the LVDS inputs, they've eased my design problems considerably over the past few years. Good job. Cheers, Syms. p.s. Note I didn't even moan about how they're compromised at high frequencies by the input capacitance. Oh bugger, I just did. ;-)Article: 101724
its an active document, called HEX viewer. on my PC it is the "F4" - I am using winXP mainly as a way to start multiply copies of FAR (clone of norton commander) so on my PC I select any xilinx .BIT file, press F4, and I see the 0xAA ... :) Antti PS sure the sync and all other details of the xilinx bitstream are documented in xilinx datasheets as well.
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