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
http://www.xilinx.com/bvdocs/appnotes/xapp780.pdf Austin Thomas Stanka wrote: > Why Ngc? > And is it necessary to stay on S3? Maybe you should think about Flash > based Fpgas (Actel, Lattice,..). > > bye Thomas >Article: 93026
Binary format and secret! Good for protecting designs against piracy but too many problems for those who want to do dynamic reconf :-( MehdiArticle: 93027
Eilert - I think your asking the wrong question when you ask 'How comes that the simpler(?) tool does the better job?' You should ask 'which tools are doing the correct job?' What if you were delibrately coding to create latches? Would you say it was doing a better job? Just my $0.02 John ProvidenzaArticle: 93028
FreeRTOS.org is an open source mini real time kernel. V3.2.4 is the first version to include a port for the Microblaze. See http://www.freertos.org/portmicroblaze.html (this is a direct link to the port docs so you will not see the menu frame. Go directly to http://www.FreeRTOS.org to see the menu). There are many existing ports, but this is my first venture into the FPGA world. As I am new to soft processors and FPGA's I might not have everything set up in the most efficient fashion - but the port has been working well on soak test for many days now. Hope it might be of interest to some (?). Regards, Richard. http://www.FreeRTOS.orgArticle: 93029
"Ray Andraka" <ray@andraka.com> wrote in message news:cd7nf.17190$Mi5.3558@dukeread07... > Bob Perlman wrote: >> On 11 Dec 2005 16:31:33 -0800, "Peter Alfke" <alfke@sbcglobal.net> >> wrote: >> >> >>>Brian, I think you overdramatize this. >> >> >> I have to agree with Brian. This is a big deal. I expected that >> violating read address setup time would screw up the read result that >> cycle; I was amazed to find out that violating address timing could >> actually change the contents of the RAM. I imagine that anyone using >> the BRAM as a ROM, with WE arc-welded to ground, would be doubly >> surprised. > > > I'm with Brian and Bob on this. As a designer, we need have limitations > like this as well as those with the FIFO16's printed in bold right in the > users guides so that it can be avoided by design rather than discovered in > the lab. Findng it in the lab is too late in the design cycle. The > question is, what other gems like this are hidden away in obscure answer > records? Ditto, ditto, ditto. As engineers, we're used to dirty laundry. Saying there's a specific design issue with a functional block that must be avoided doesn't turn the designers into silicon hating neanderthals like part availability issues. We know designs aren't 100%. We produce them ourselves. If we design *to the silicon* we need to *know* the silicon. Silicon vendors: Be forthcoming and you will get a reputation of working with the designers, not of frustrating them. The end result is *increasing* sales by partnering with the designers rather than losing sales to disgruntled engineers.Article: 93030
Hi everyone: From the point of view of EMI (or any type of interference), are FPGAs devices so relyable as ASIC or industrial micro? I was thinking in a case like this: Due to any interference, a small part of the FPGA is deconfigured and affect in any manner to the global working. Is this possible? ThanksArticle: 93031
"calaf" <calaf_calaf_calaf@yahoo-dot-es.no-spam.invalid> wrote in message news:Kt6dna8t7PXYLQDeRVn_vQ@giganews.com... > Hi everyone: > From the point of view of EMI (or any type of interference), are FPGAs > devices so relyable as ASIC or industrial micro? I was thinking in a > case like this: Due to any interference, a small part of the FPGA is > deconfigured and affect in any manner to the global working. Is this > possible? > Thanks > If you are talking flash based FPGA's such as Altera MaxII parts then no, however, if you are using the larger Cyclone/Stratix I&II parts which boot from external flash then yes, it is possible and has been known to occur in severe EMI environments. However the Altera parts have provision in the embedded chip hardware to continuously check the contents of the internal configuration via a CRC which is loaded on boot. If the continuous background check fails an immediate auto reboot from external flash can be initiated. Don't know about Xilinx parts, I expect, as always, they are perfect in every detail - in theory. SlurpArticle: 93032
calaf wrote: > Hi everyone: > From the point of view of EMI (or any type of interference), are FPGAs > devices so relyable as ASIC or industrial micro? I was thinking in a > case like this: Due to any interference, a small part of the FPGA is > deconfigured and affect in any manner to the global working. Is this > possible? > Thanks SRAM-based Fpgas are susceptible to soft errors arising from neutron radiation (Use google to get details). Actel for example use Flash-based and anti-fuse technologies to avoid this probem. AlanArticle: 93033
Hi, I use a Virtex XCV300 I would like to do : a multi *3 and a div /2 with a clk = 32 MHz. (I would like to obtain a freq = 48 MHz) Can you help me !!. Thanks and regards, Benoit.Article: 93034
Benoit, You could double your 32MHz with a DLL to get 64MHz. Then use a clock enable to select just 3 out of four clocks. You don't mind a little jitter do you? Better still, (and I write this in the style of Mr. Alfke ;-)) the Virtex part to a museum sell, and a modern FPGA with a DCM get. Cheers, Syms. "HB" <bhb22l@yahoo.fr> wrote in message news:dnkdo8$7ps$1@s1.news.oleane.net... > Hi, > > I use a Virtex XCV300 > I would like to do : a multi *3 and a div /2 with a clk = 32 MHz. > (I would like to obtain a freq = 48 MHz) > > Can you help me !!. > Thanks and regards, > > Benoit. > >Article: 93035
Calaf, The concern is with the metal interconnect on the die, as there is nothing we can do for the metal wires on the pcb. For wiring on the pcb, voltages of 1 volt might disturb an IO signal (on any chip). For wiring inside the FPGA, a voltage of a few hundred millivolts couls also upset the operation of the chip (change a logic value of a signal). If the longest internal wire for the largest device is 2 centimeters long, what is the potential that is imposed on it by your EMI/RFI environment? E&M Field theory equations are used to solve this. Look at as one turn transformer with one turn being partial, 2cm long, located the distance that is to be simulated away from your other turn which creates the magnetic field....two square loops coupling can be used to estimate, dividing the results by 4 for just the partial turn... It is likely the wiring on the pcb is the first to fail, as these wires are much longer than even the longest wires on die. But, if you have considered the pcb wiring, and kept that very short, then you must also consider the on die wiring. Placing the pcb orthogonal to the fields will go a very long way in mitigation for both the pcb, and the die (as the wiring is in the same plane for both). Places people are concerned about this include: train motor controls, MRI scanners, and any other environment where very large magnetic field transients will occur. Austin calaf wrote: > Hi everyone: > From the point of view of EMI (or any type of interference), are FPGAs > devices so relyable as ASIC or industrial micro? I was thinking in a > case like this: Due to any interference, a small part of the FPGA is > deconfigured and affect in any manner to the global working. Is this > possible? > Thanks >Article: 93036
I would suggest using a small external clock multiplier like the 8-pin SOIC ICS501 to multiply the 32 MHz by three. There is no PLL in the Virtex or Virtex E series. Symon wrote: > Benoit, > You could double your 32MHz with a DLL to get 64MHz. Then use a clock enable > to select just 3 out of four clocks. You don't mind a little jitter do you? > Better still, (and I write this in the style of Mr. Alfke ;-)) the Virtex > part to a museum sell, and a modern FPGA with a DCM get. > Cheers, Syms. > > "HB" <bhb22l@yahoo.fr> wrote in message > news:dnkdo8$7ps$1@s1.news.oleane.net... > > Hi, > > > > I use a Virtex XCV300 > > I would like to do : a multi *3 and a div /2 with a clk = 32 MHz. > > (I would like to obtain a freq = 48 MHz) > > > > Can you help me !!. > > Thanks and regards, > > > > Benoit. > > > >Article: 93037
calaf wrote: > Hi everyone: > From the point of view of EMI (or any type of interference), are FPGAs > devices so relyable as ASIC or industrial micro? I was thinking in a > case like this: Due to any interference, a small part of the FPGA is > deconfigured and affect in any manner to the global working. Is this > possible? > Thanks > We've had a discussion today about quite the same question at the university. We concluded, that FPGAs are not less safer than an industrial computer with the same housing. Of course not as safe as an ASIC device, but still, it is a very good alternative for industrial computers/PLCs/etc. Good luck -- Vitya balogh.viktor@chello.huArticle: 93038
backhus wrote:
>
>> A single line with the default, right before the case statement
>> in DCM_comb, should do it:
>>
>> DCM_NextState <= DCM_CurrentState;
>>
>> Jan
>>
> Hi Jan,
> You are right. I also thought about that, but somehow I expected it to
> create latches as well. Strange, since I'm using the
> defaults-before-case style a lot. Fooled by too much routine possibly :-)
>
> But still, ISE created a latch free result before that change.
> Maybe one could complain about a missing warning.
> And even after the proposed correction ISE created a smaller and faster
> result than Precision RTL. (Synopsys dc also created something latchfree
> but again the FSM extraction failed, so further optimisation wasn't
> possible)
>
> How comes that the simpler(?) tool does the better job?
Perhaps it doesn't, unfortunately. It may be that you are seeing a
bug that happens to do the right thing in this particular case.
Let's consider the combinatorial part separately, and suppose the
control conditions are such that the default applies. With the
default assigment, next state will combinatorially follow current
state. But without it, as in your original code, it should keep its
old value, as per VHDL semantics. So you need memory elements.
Now, you can argue that the memory elements are the flip-flops
in the feedback loop of the overall circuit. And that current
state cannot change unless the control conditions are such that
the default does *not* apply. If ISE uses that info to
avoid the latches, it is more intelligent indeed.
But my guess is that that's not what happening. To test this,
synthesize the combinatorial part on it own. ISE cannot know
how it is used now. Does it now infer latches or issue a
warning? It not, then that's a bug and you were just
lucky in the original case. Otherwise, we would like
to know!
BTW, the truly intelligent thing to do would be to refuse to
infer latches and issue an error. The latch control logic
will be so glitchy that such a circuit cannot possibly
work reliably in practice.
Jan
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com
Article: 93039HB, In Virtex, the DLL may be used for mutliply by 2. That gets you to 64 MHz. Then a subsequent DLL may be used for divide by 1.5 to get 48 MHz. Or, you may use a /1.5 circuit made out of FF's and a LUT. http://www.xilinx.com/xcell/xl33/xl33_30.pdf Austin HB wrote: > Hi, > > I use a Virtex XCV300 > I would like to do : a multi *3 and a div /2 with a clk = 32 MHz. > (I would like to obtain a freq = 48 MHz) > > Can you help me !!. > Thanks and regards, > > Benoit. > >Article: 93040
"Austin Lesea" <austin@xilinx.com> wrote in message news:dnku2g$f699@xco-news.xilinx.com... > HB, > > In Virtex, the DLL may be used for mutliply by 2. That gets you to 64 > MHz. Then a subsequent DLL may be used for divide by 1.5 to get 48 MHz. > > Or, you may use a /1.5 circuit made out of FF's and a LUT. > > http://www.xilinx.com/xcell/xl33/xl33_30.pdf > > Austin > Would be a great solution, except that, sadly, 64MHz divided by 1.5 is 42.667 MHz, or thereabouts. Cheers, Syms.Article: 93041
So it is.... Looks like getting 48 MHz from 32 MHz is not going to be as easy as it first appears! What kind of output duty cycle and max jitter is needed? Austin Symon wrote: > "Austin Lesea" <austin@xilinx.com> wrote in message > news:dnku2g$f699@xco-news.xilinx.com... > >>HB, >> >>In Virtex, the DLL may be used for mutliply by 2. That gets you to 64 >>MHz. Then a subsequent DLL may be used for divide by 1.5 to get 48 MHz. >> >>Or, you may use a /1.5 circuit made out of FF's and a LUT. >> >>http://www.xilinx.com/xcell/xl33/xl33_30.pdf >> >>Austin >> > > Would be a great solution, except that, sadly, 64MHz divided by 1.5 is > 42.667 MHz, or thereabouts. > Cheers, Syms. > >Article: 93042
Hi Antti
as later i told i stated from Reader ... and i am facing
problem in crc-7 ... i know that serial crc is easy but it will take
more time so i was trying for table based crc approach ... but its a
little more complex ...
whats your suggestion for that ...
and also I got your code and trying to understand and learn from
it(as your coding style is much better and professional than me) ...
but i have some questions about ur code ...
1) stream read ?
2) crc7 is right ?
3) standard 3.1 (7 pin) ?
and one more question ...
Is there any way to avoid crc in command as for
developing reader i got help from sandisk datasheet and also of
hitachi ... and in that although I not found any kind of such
description ... but in one example in datasheet i felt that to ignore
crc he was puting all crc bits one(1111111) ...is it true ?
Article: 93043Hello everyone, I'm currently using Xilinx ISE 7.1i with the ModelSim XE III/Starter 6.0a simulator. The FPGA which I am downloading my design onto is a Spartan IIE (it's on the Spartan IIE LC Development Kit, with an XC2S300E device). A word of thanks to all those who have helped me in my previous posts before; you've all been a big, BIG help, and I really appreciate it. I finally found the root of the problem I was having before. The translated verilog model, when simulated, gives me wrong outputs, as compared to the behavioural model. After thorough checking of the simulation results, I realised that all my inputs were wrongly translated and mapped! My mapped inputs were all in a haywire (e.g. clock has become reset, reset has become cs, sck has become another signal, etc.). Is this the tool's limitation? There were no errors in my design. Neither were there any errors in my Translate, Map or PAR reports. I ran an Assign Package Pins Post-Translate, but I'm not sure if I should make any changes to the LOC-ed input and outpins which I did earlier in Edit Constraints (Text). Any suggestions as to how I can solve this problem? Please help. Thanks very much in advance. Regards, ChloeArticle: 93044
Dear all, I am new in FPGA field. I am working on designing Logic board for PDP (Plasma display panel). My question is 1. can any one tell me which Xilinx processor is suitable for PDP applicaton? 2. Can any one tell me where I can get basic knowladge about FPGA Thanks in Advance, SandeepArticle: 93045
hwguy wrote: > Dear all, > I am new in FPGA field. I am working on designing Logic board for PDP > (Plasma display panel). > My question is 1. can any one tell me which Xilinx processor is > suitable for PDP applicaton? > 2. Can any one tell me where I can get basic knowladge about FPGA > > > Thanks in Advance, > Sandeep > First off, the Xilinx parts are not processors, although a processor can certainly be designed into one. Any of the field programmable gate arrays would be suitable for a PDP, presuming you have the necessary level translators between the 3.3v or less FPGA outputs and the PDP inputs. The size of the FPGA depends on what logic you need to drive the display panel and to realize the functions you want to include in your design. FPGA design is digital logic circuit design. If you don't have experience with digital logic circuit design, I would strongly suggest finding someone who is versed in this discipline to help you out with the design. You can get the basic knowledge of what an FPGA is by reading the data sheets, user guides and application notes from the FPGA vendor.Article: 93046
Hi, If I have done a circuit design and I want to use it in an acutal environment, I want to my chip to run as fast as possible but what is the max value, which determines it? Thanks a lot. Binary ChenArticle: 93047
Thanks, xapp780 is good food for the mind, and I think we would have to design our own (Vanilla microcontroller) that would mimic a DS2432 secure controller-key. One thing though, would xilinx enhance the security feature of their S3 line? And finally, in case of a virtex2, can a design gain access to the registers that hold the encryption keys. In response to Thomas, all our products are X based, so we dont have many choices. And as we dont want to provide our customers access to the high level code, the only way to give them a usable core is to have the design in a compiled obfuscated netlist file. JA Austin Lesea wrote: > http://www.xilinx.com/bvdocs/appnotes/xapp780.pdf > > Austin > > Thomas Stanka wrote: > > > Why Ngc? > > And is it necessary to stay on S3? Maybe you should think about Flash > > based Fpgas (Actel, Lattice,..). > > > > bye Thomas > >Article: 93048
On 12 Dec 2005 19:00:04 -0800, "Chloe" <chloe_music2003@yahoo.co.uk> wrote: >Hello everyone, > >I'm currently using Xilinx ISE 7.1i with the ModelSim XE III/Starter >6.0a simulator. The FPGA which I am downloading my design onto is a >Spartan IIE (it's on the Spartan IIE LC Development Kit, with an >XC2S300E device). > >A word of thanks to all those who have helped me in my previous posts >before; you've all been a big, BIG help, and I really appreciate it. > >I finally found the root of the problem I was having before. The >translated verilog model, when simulated, gives me wrong outputs, as >compared to the behavioural model. After thorough checking of the >simulation results, I realised that all my inputs were wrongly >translated and mapped! > >My mapped inputs were all in a haywire (e.g. clock has become reset, >reset has become cs, sck has become another signal, etc.). Is this the >tool's limitation? There were no errors in my design. Neither were >there any errors in my Translate, Map or PAR reports. I ran an Assign >Package Pins Post-Translate, but I'm not sure if I should make any >changes to the LOC-ed input and outpins which I did earlier in Edit >Constraints (Text). > >Any suggestions as to how I can solve this problem? Please help. > >Thanks very much in advance. > >Regards, >Chloe yes, there is one important improvement: do assign package-pins pre-translate. In such a way, every pñin will be correctly assigned from the beginning. Assigning pins post-translate is simply a tool fro some kind of tests, it is not a tool for production. Regards, -- ZaraArticle: 93049
Zara: Hi, and thanks for your advice. I did assign package-pin pre-translate, and I deduced from the Translate Report that all the I/O pins were assigned and translated properly as there were no errors in the report. Thus I wonder how Assign Package Pins Post-Translate is used, if I have already done a pin assignment before I even synthesised my design. I just do not understand how my I/O pins could be translated wrongly. Could it be that I mis-configured the ISE? Thanks. ~Chloe~
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