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
[My initial msg.] > > [Context is wanting to run a DLL at 24 MHz when the min spec is 25.] > > > > > Now, I am assuming you are not going below 0C, so there will be some > > > margin there. But if not, then definitely don't do it. > > > > In general, CMOS prop time is linear in temp and supply voltage. He's > > only off by 4% so we should be able to draw the forbidden zone on a graph > > with voltage on one axis and temp on the other. > > > > Does that sort of reasoning work with DLLs? > > In article <3A561466.534B42DB@xilinx.com>, Austin Lesea <austin.lesea@xilinx.com> writes: > Hal, > > Yes. > > I just can't say "go ahead" for all of the reasons I stated. Someday, some > lot might be just a little too fast (even though it is pretty unlikely). That's exactly the point I was trying to make. Why can't you say "go ahead"? Is there a flaw in my reasoning or is that due to legal issues? In most interesting projects, a designer has to use a lot of information that isn't in the data sheet. What's the "contract" between the vendor and the designer? How can I be sure that a design will work correctly if I use information from app notes or general common sense or rumors from usenet? Note that there are two types of extra information. One is things like how to get the tools to do what you want or explainations of what a particular line on the data sheet really means. The other type of information is extra - things you won't find in the data sheet at all. The obvious example is speed being linear with temperature and VCC. In this context, I guess that some of the tools are part of the contract, next to the data sheet. I'm thinking of the timing verifier or report generator and the power estimator. The particular case that I proposed is tricky because it depends upon minimum prop times and the general party line is things might go faster. But in this particular case, there is a requirement for that min in the spec sheet. The spec sheet says it will work down to 25 MHz. Most people know it's "legal" to reduce the prop times in a data sheet if you can keep a part cool and/or keep the VCC above min. My proposal uses the same approach, just with the reverse sign bit. If it will work at 25 MHz at max VCC, will it run at 24 MHz if I keep VCC at least 5% below max? -- These are my opinions, not necessarily my employers. I hate spam.Article: 28426
Well, the delay becomes longer and less precise. So the "clock" signal is delayed. Whether that matters depends on your total timing. Peter A erika_uk@my-deja.com wrote: > thanks peter, > i was just thinking if there is any negative points from routing the > clk net through the non dedicated routing ressources > > In article <3A5DE811.C46239FF@xilinx.com>, > peter.alfke@xilinx.com wrote: > > > > --------------674E81B0FE10E2CB432BC052 > > Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x- > mac-creator="4D4F5353" > > Content-Transfer-Encoding: 7bit > > > > erika_uk@my-deja.com wrote: > > > > > hi all, > > > > > > Is there any harm from using the clock net to drive some ram > address. ( > > > one address wire for example toggle between 1 and zero), > > > > > > > No, no harm. The address input doesn't know anything about the source > of > > its signal. If you wiggle very fast, the power consumption may go up. > But > > no real problem. What makes you even think so? > > > > Peter Alfke > > > > --------------674E81B0FE10E2CB432BC052 > > Content-Type: text/html; charset=us-ascii > > Content-Transfer-Encoding: 7bit > > > > <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> > > <html> > > > > <p>erika_uk@my-deja.com wrote: > > <blockquote TYPE=CITE>hi all, > > <p>Is there any harm from using the clock net to drive some ram > address. > > ( > > <br>one address wire for example toggle between 1 and zero), > > <br><a href="http://www.deja.com/"></a> </blockquote> > > No, no harm. The address input doesn't know anything about the source > of > > its signal. If you wiggle very fast, the power consumption may go up. > But > > no real problem. What makes you even think so? > > <p>Peter Alfke > > <br> </html> > > > > --------------674E81B0FE10E2CB432BC052-- > > > > > > Sent via Deja.com > http://www.deja.com/Article: 28427
In article <Xns902683BA6shivawellcom@207.126.101.100>, shiva@well.com (Kenneth Porter) wrote: > bjrosen <bjrosen@polybus.com> wrote in <93jj36$c4a$1@nnrp1.deja.com>: > > >Windows systems suffer from DLL hell, there is no > >equivalent on Linux. When you install a new program on Linux you never > >have to worry that it will stomp on some other program. On Windows you > >have a 50/50 chance of mangling your system every time you install > >something. > > Why does Windows suffer from DLL hell, but Linux doesn't? Both use shared > libraries. When Windows apps install DLL's into the system directory, isn't > it usually to deal with a prior shortcoming in Windows? Might we not see > apps trying to do the same thing in Linux, installing their own updates to > system libraries, like libc, gtk, or kde? (Experienced developers and > admins won't allow this, but what about inexperienced developers coupled > with ignorant users?) > The Redhat Package Manager makes sure that this doesn't happen on Linux. When you do an install it checks all of the dependencies and tells you what applications you are going to break. On Windows every installer assumes that it's free to replace anything it wants. Also on Linux you can use different libraries for every app if you want, thats what the LD_LIBRARY_PATH env variable is for. Sent via Deja.com http://www.deja.com/Article: 28428
Bill Lenihan <lenihan3weNOSPAM@earthlink.net> writes: > I know how to make binary up/down counters and LFSR-based counters in > verilog, but does anyone know of an algorithmic/equation-based way to > make grey-code counters? > > The only examples I've seen are from old PAL application notes, and they > are for 4-bit grey counters that are described as 16-state state > machines, which is ok if you are keeping the counter at 4-bits, but > impractical if you are going to much wider bit widths. When I wanted the same thing, a generic grey code counter, without having to do it manually for each bit-width, I did the following: Created an bin2grey function, and a grey2bin function, each of which converted a unsigned or slv of any width from grey to bin or vice-versa. When I went to implement it, I wrote: next_grey_counter <= bin2grey( grey2bin( grey_counter ) +1 ); and let my synthesizer loose on ity to see what it came up with. I'm sure this isn't the highest performance way of doing it, but for moderate speeds, it *is* easy. Synthesized with Foundation Express v3.3, each counter has Reset, Clk, Enable, and Count output, counting up only. Counter 4-input FFs CYs Width LUTs 4 4 4 5 8 5 6 9 6 7 11 7 20 38 20 19 I place and routed all of these counters in a Spartan-II 150-5, not adjusting any synthesis or place-and-route options, and came up with a frequency of 160MHz for the 7-bit counter. Anyone who's intereseted in the code (VHDL only.) is welcome to it, just let me know. -KentArticle: 28429
Kenneth Porter wrote: > > bjrosen <bjrosen@polybus.com> wrote in <93jj36$c4a$1@nnrp1.deja.com>: > > >Windows systems suffer from DLL hell, there is no > >equivalent on Linux. > > Why does Windows suffer from DLL hell, but Linux doesn't? Both use shared > libraries. Yes, but usually in Linux/Unix contain file names the version of a shared lib. Therefore you can have different versions of the same lib installed. You can solve problems concerning different programs which need different versions of the same library with an appropriate symbolic link. Furthermore, one can use the ldd-command for checking whether the needed libraries are available. -- Dipl.-Ing. Thomas Reinemann IMAT Otto-von-Guericke-Universität Magdeburg Universitätsplatz 2 39106 Magdeburg GermanyArticle: 28430
This is a multi-part message in MIME format. --------------1543F5974182AF4E64D9DA8B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have to configure 3 APEX20K1500 by a Flash memory controller. I chosen a PPA scheme for the configuration (Doc. : Altera AN116) My questions is: After first device's configuration... - Do I have to move again the signals nCONFIG, nCS and CS for the second and the third device? Thanks in advance! --------------1543F5974182AF4E64D9DA8B Content-Type: text/x-vcard; charset=us-ascii; name="Fernando.Meta.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Meta Fernando Content-Disposition: attachment; filename="Fernando.Meta.vcf" begin:vcard n:Meta;Fernando x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:Fernando.Meta@tei.ericsson.se note:Hardware Designer x-mozilla-cpt:;-7088 fn:Fernando Meta end:vcard --------------1543F5974182AF4E64D9DA8B--Article: 28431
Hi Luigi, > >Hi, >Does anyone know what devices are supported by the >free Altera development software? >It is not clear on the Altera web pages, >and I would know it before download a lot of >MBytes. I'm specially interested in FLEX 8000 >family. Thanks! > Try a quick browse at... http://www.altera.com/html/tools/emax_baseline.html Cheers, Martin -- Martin Thompson BEng(Hons) MIEE TRW Automotive Advanced Product Development, Stratford Road, Solihull, B90 4GW. UK Tel: +44 (0)121-627-3569 mailto:martin.j.thompson@trw.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 28432
Thankyou for any help. Please could someone point me to the relevant information on the folowing subjects. 1) What does the basic FPGA SRAM cell or element look like? A description of how it is constructed (to the component level - transistors, resistors etc.) and a diagram of a single cell (does it look like a six transistor SRAM memory cell or does it differ?) would be very useful. 2) Has any failure analysis been carried out on the SRAM elements themselves and if so where can I get the results please? Has anyone any useful information on failures of the SRAM cells? 3) What is the effectiveness of the engineering and stability of programming configuration. For example if an SRAM FPGA is left powered but unused for a period of time, say a few weeks, at the end of this period would the SRAM element, and hence the FPGA itself, still be exactly as it was when originally programmed? Thankyou.Article: 28433
On Thu, 11 Jan 2001 14:28:13 -0500, "Jamie Sanderson" <jamie@nortelnetworks.com> wrote: >I think I have a good understanding of CRCs, and I can work out examples on >paper or follow the various software examples given. Where I'm stuck is in >understanding how to go from the definition of the CRC to the requisite XOR >statements, as seen in code generated by Jan's CRC tool. I would greatly >appreciate a pointer to this information. While I could just use the code I >have, I'd much rather understand how it was made. What you want (I think) is info on how to do a parallel factorisation. The best reference I've seen is an old AMD app note for TAXI devices, which unfortunately I've lost (if you can find it online I'd appreciate a link). Jack Ganssle also wrote an article in 1991 on how to do it, which he's got at http://www.ganssle.com/articles/acrc.htm. I went through this in detail a few years ago and decided that it has problems with CRC inversion and bit ordering, but it's a good start if you can't find the AMD ref. EvanArticle: 28434
In article <3A5C2AE9.52717DAD@earthlink.net>,
lenihan3weNOSPAM@earthlink.net wrote:
> I know how to make binary up/down counters and LFSR-based counters in
> verilog, but does anyone know of an algorithmic/equation-based way to
> make grey-code counters?
Here is a VHDL package to use gray-code structures in a high-level
manner. Below that is a sample program that uses the package.
- WJ
------------------------------------------------------------------------
------
library ieee;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
package gray_pkg is
type gray is array (natural range <>) of std_logic;
function TO_GRAY (arg: unsigned) return gray;
function TO_GRAY (arg, size: natural) return gray;
function TO_UNSIGNED (arg: gray) return unsigned;
function TO_INTEGER (arg: gray) return natural;
function "+" (l: gray; r: natural) return gray;
function "-" (l: gray; r: natural) return gray;
function "=" (l: gray; r: natural) return boolean;
end gray_pkg;
package body gray_pkg is
function TO_GRAY (arg: unsigned) return gray is
begin
return gray(arg xor '0' & arg(arg'LEFT downto arg'RIGHT+1));
end; -- TO_GRAY
function TO_GRAY (arg, size: natural) return gray is
begin
return TO_GRAY(TO_UNSIGNED(arg, size));
end; -- TO_GRAY
function TO_UNSIGNED (arg: gray) return unsigned is
variable vect: unsigned(arg'RANGE);
begin
vect := unsigned(arg);
for i in vect'LEFT-1 downto VECT'RIGHT loop
vect(i) := vect(i+1) xor vect(i);
end loop;
return vect;
end; -- TO_UNSIGNED
function TO_INTEGER (arg: gray) return natural is
begin
return TO_INTEGER(TO_UNSIGNED(arg));
end; -- TO_INTEGER
function "+" (l: gray; r: natural) return gray is
variable vect : unsigned(l'RANGE);
variable num : natural;
begin
return TO_GRAY(TO_UNSIGNED(l) + r);
end; -- "+"
function "-" (l: gray; r: natural) return gray is
begin
return TO_GRAY(TO_UNSIGNED(l) - r);
end; -- "-"
function "=" (l: gray; r: natural) return boolean is
begin
return r = TO_UNSIGNED(l);
end; -- "="
end gray_pkg;
------------------------------------------------------------------------
------
library ieee;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
use WORK.gray_pkg.all;
entity gray_tst is
port (
Rst : in std_logic; -- High active reset.
Clk : in std_logic; -- Clock.
Ena : in std_logic; -- Active-high syncronous count
enable.
Cnt : out std_logic_vector(9 downto 0));-- Gray code
count.
end gray_tst;
architecture rtl of gray_tst is
signal cnt_q : gray(9 downto 0); -- Counter register bits.
begin --rtl
------------------------------------------------------------------------
------
-- cnt_reg - gray counter that counts from 700 to 779
------------------------------------------------------------------------
------
cnt_reg : process (Clk, Rst)
begin -- cnt_reg
if (Rst = '1') then
cnt_q <= TO_GRAY(700, cnt_q'LENGTH);
elsif (Clk'event and Clk = '1') then
if ( Ena = '1' ) then
if ( cnt_q = 779 ) then
cnt_q <= TO_GRAY(0, cnt_q'LENGTH);
else
cnt_q <= cnt_q + 1;
end if;
end if;
end if;
end process cnt_reg;
Cnt <= std_logic_vector(TO_UNSIGNED(cnt_q));
end rtl;
Sent via Deja.com
http://www.deja.com/
Article: 28435Andy Peters writes: > ModelSim and Synplify both use dongles (which I vastly prefer over > that FlexLM bogosity) but the Mac ain't got a parallel port so I'm SOL > there. And even if the MAC did have a parallel port... I vastly prefer FlexLM because there is some hope of it working in an emulator. In my experience dongle reading code does seriously weird things to your parallel port, and doesn't work in an emulator. -- JamieArticle: 28436
I guess what I thought was a clear question really wasn't, since I've had a
number of responses which didn't address the issue. (not that I don't
appreciate the effort)
I think it would be illuminating if I posted an example of Jan's code. To
keep it short, I used the polynomial from E1, which is a CRC-4 with a
generating polynomial of x^4 + x + 1, calculated over a byte.
Looking at the code below, you'll find that it contains a set of four XOR
statements which compute successive values of the CRC. What I don't
understand is how these statements were generated. Clearly there is an
algorithm for doing this since Jan's tool obviously makes use of one. I'd
like to know what that is (assuming it's not proprietary).
Regards,
Jamie
///////////////////////////////////////////////////////////////////////
// File: CRC4_D8.v
// Date: Fri Jan 12 15:42:09 2001
//
// Copyright (C) 1999 Easics NV.
// This source file may be used and distributed without restriction
// provided that this copyright statement is not removed from the file
// and that any derivative work contains the original copyright notice
// and the associated disclaimer.
//
// THIS SOURCE FILE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS
// OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
// WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
//
// Purpose: Verilog module containing a synthesizable CRC function
// * polynomial: (0 1 4)
// * data width: 8
//
// Info: jand@easics.be (Jan Decaluwe)
// http://www.easics.com
///////////////////////////////////////////////////////////////////////
module CRC4_D8;
// polynomial: (0 1 4)
// data width: 8
// convention: the first serial data bit is D[7]
function [3:0] nextCRC4_D8;
input [7:0] Data;
input [3:0] CRC;
reg [7:0] D;
reg [3:0] C;
reg [3:0] NewCRC;
begin
D = Data;
C = CRC;
NewCRC[0] = D[6] ^ D[4] ^ D[3] ^ D[0] ^ C[0] ^ C[2];
NewCRC[1] = D[7] ^ D[6] ^ D[5] ^ D[3] ^ D[1] ^ D[0] ^ C[1] ^ C[2] ^
C[3];
NewCRC[2] = D[7] ^ D[6] ^ D[4] ^ D[2] ^ D[1] ^ C[0] ^ C[2] ^ C[3];
NewCRC[3] = D[7] ^ D[5] ^ D[3] ^ D[2] ^ C[1] ^ C[3];
nextCRC4_D8 = NewCRC;
end
endfunction
endmodule
"x-guy" <x-guy@hotmall.com> wrote in message
news:3A5E4DCC.695200B6@hotmall.com...
> Don't understand what your question is. Are you talking about how to code
in
> HDL or how to find those polynomial?
>
> Jamie Sanderson wrote:
>
> > Greetings;
> >
> > I need to implement a small CRC function in an FPGA design I'm currently
> > working on. I've scoured the net for information, and have read (and
> > re-read) various articles:
> >
> > http://www.netrino.com/Connecting/2000-01/index.html by Michael Barr
> > ftp://ftp.rocksoft.com/clients/rocksoft/papers/crc_v3.txt by Ross
Williams
> >
> > I've also generated the code I need using Jan Decaluwe's CRC tool
> > (http://www.easics.com/webtools/crctool).
> >
> > I think I have a good understanding of CRCs, and I can work out examples
on
> > paper or follow the various software examples given. Where I'm stuck is
in
> > understanding how to go from the definition of the CRC to the requisite
XOR
> > statements, as seen in code generated by Jan's CRC tool. I would greatly
> > appreciate a pointer to this information. While I could just use the
code I
> > have, I'd much rather understand how it was made.
> >
> > Thanks,
> > Jamie
>
Article: 28437Hi The exact message is : # ** Warning: */APEX20k_ASYNCH_MEM SETUP High VIOLATION ON WADDR(1) WITH RESPECT TO WE; # Expected := 2.06 ns; Observed := 1.41 ns; At : 49989.401 ns # Time: 49989401 ps Iteration: 4 Instance: /test/i1/i1_ai3_ai2_ai1_alpm_ram_dp_component_asram_asegment_a0_a_a4_a/apexm em # ** Warning: */APEX20k_ASYNCH_MEM SETUP Low VIOLATION ON WADDR(0) WITH RESPECT TO WE; # Expected := 2.06 ns; Observed := 1.41 ns; At : 49989.401 ns # Time: 49989401 ps Iteration: 4 Instance: /test/i1/i1_ai3_ai2_ai1_alpm_ram_dp_component_asram_asegment_a0_a_a4_a/apexm em .... Michel Le Mer. S.K. Sharma <sanjay.kumar.sharma@philips.com> a écrit dans le message : 93hoat$r9c$1@porthos.nl.uu.net... > Hi Michel, > Could you post the exact error message! > Thanks > Sanjay > > -- > Sanjay Kumar Sharma > ASIC Design Engineer > Philips Semiconductors > Eindhoven, The Netherlands > "Le Mer Michel" <michel.lemer@sta.fr> wrote in message > news:93c9gj$kk4$1@s1.read.news.oleane.net... > > Hello > > > > I have a strange message about APEX20K_ timing violation during simulation > > despite I use the APEX 20KE family and that all the frequencies are met > > according to Quartus. > > > > Any suggestions? > > > > Thanks > > -- > > Michel Le Mer immeuble Cerium > > STA 12, square du Chene Germain > > 02 23 20 04 72 35510 Cesson-Sevigne > > > > > > >Article: 28438
Hi there, can anybody give me good references for stereo vision algorithms which are best suited for the parallel execution nature of FPGAs to better solve the correspondence problem using a correlation based approach? I know about the CMU group using DSPs and so on, but FPGA designs are rather hard to find, but should in my eyes be far superior in performance. (small overview is included in Kurt Konolige's "Extra-Pair-Of-Eyes" DSP-design) I would like to use a Xilinx Virtex-1000 board running @ 100MHz for this task. Thanks in advance! Sincerely, Sven Fleck ---------------------------------- Sven Fleck University of Tuebingen GermanyArticle: 28439
--------------B8C7AD462CF21207EA77122C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hal, I will comment below. Austin Hal Murray wrote: > [My initial msg.] > > > > [Context is wanting to run a DLL at 24 MHz when the min spec is 25.] > > > > > > > Now, I am assuming you are not going below 0C, so there will be some > > > > margin there. But if not, then definitely don't do it. > > > > > > In general, CMOS prop time is linear in temp and supply voltage. He's > > > only off by 4% so we should be able to draw the forbidden zone on a graph > > > with voltage on one axis and temp on the other. > > > > > > Does that sort of reasoning work with DLLs? > > > > > In article <3A561466.534B42DB@xilinx.com>, > Austin Lesea <austin.lesea@xilinx.com> writes: > > Hal, > > > > Yes. > > > > I just can't say "go ahead" for all of the reasons I stated. Someday, some > > lot might be just a little too fast (even though it is pretty unlikely). > > That's exactly the point I was trying to make. Why can't you say "go ahead"? > Is there a flaw in my reasoning or is that due to legal issues? There is an implicit contract here. We state in the specifications that the product will do X. If it doesn't do X, you get it replaced with one that does. > > > In most interesting projects, a designer has to use a lot of information > that isn't in the data sheet. What's the "contract" between the vendor > and the designer? How can I be sure that a design will work correctly > if I use information from app notes or general common sense or rumors > from usenet? Spec sheet = contract. App note = we will support it just like the spec sheet. A email from a Xilinx engineer is a written document, so it also must be treated as a statement of 'suitablity for use' ... ie we would have to supply chips that do what was said. Thus, my caution. Anything else, well, have fun. > > > Note that there are two types of extra information. One is things like > how to get the tools to do what you want or explainations of what a > particular line on the data sheet really means. > > The other type of information is extra - things you won't find in the > data sheet at all. The obvious example is speed being linear with > temperature and VCC. True. There are a lot of implicit assumptions engineers make everday. I did it for 20 years in telecom, and I still have to do it now. Sometimes the common knowledge isn't all that common, and it may not be true (e.g. maybe there is temperature compensation in the circuit, and it isn't getting faster as it gets colder, or there is a voltage regulator hidden on chip that we don't talk about). Usually a phone call, or an email will clear up little things like that. That is what this question was all about -- is there any reason why one shouldn't use it at 24 MHz? I went around, and unanimously everyone said "no problem," but then I asked OK, so then why don't we change the spec? No takers. 0, Nada. So, if the spec won't change, I can not recommend its use -- for all of thereasons stated. > > > In this context, I guess that some of the tools are part of the contract, > next to the data sheet. I'm thinking of the timing verifier or report > generator and the power estimator. Yes. > > > The particular case that I proposed is tricky because it depends upon > minimum prop times and the general party line is things might go faster. > > But in this particular case, there is a requirement for that min in the > spec sheet. The spec sheet says it will work down to 25 MHz. > > Most people know it's "legal" to reduce the prop times in a data sheet > if you can keep a part cool and/or keep the VCC above min. My proposal > uses the same approach, just with the reverse sign bit. If it will > work at 25 MHz at max VCC, will it run at 24 MHz if I keep VCC at least > 5% below max? OK. Now that is a good question. If you kept the Vccint below the recommended maximum limit by 5%, you have gained some margin. If you additionally never go below 10 C (an asian indoor telecom limit -- it never really gets cold in Taiwan or Hong Kong), they you have some more margin. But remember the comments about the possibility of a hidden voltage regulator, and temperature compensation? Maybe the margin gained isn't all that much. > > > -- > These are my opinions, not necessarily my employers. I hate spam. What I would do, if there was a clear reason to do this (save a ton of money, or make the board smaller, or ...) is to take apart, find the low frequency limit, and then change the voltage, and change the temperature, and see how it changes. I'll save you some of the work: the voltage is regulated for part of the circuit, so it won't get as fast as expected with voltage. There was also a lot of work on removing temperature sensitivity, but it is still there. The DLL will get faster as it gets colder, but not faster as fast as the core logic. Then, I would see what my margin is. If I have a 2X margin, then I would probably just go to it, and be done with it (standard engineering derating). If my margin was only 50%, then I probably still would go ahead, as it would take a lot of process changes, and perhaps even design changes to eat that up -- but I could never be sure. I might put in place an incoming inspection, and I might ask for a letter from my distributor to inform me of any change to the process on that part (a standard service for customers). I always got that letter in my telecom job, because in telecom, if anything changes, it scares the hell out of the phone companies. They have only been in business for 130+ years, so they know that change = bad in any design. Changes in components required an immediate re-qualification of the product, regardless of the change (unless it was the ink on the top, or some other silly change). When Matra changed the 80C31 (did a shrink for yield and cost), they shrank a transistor pullup that should have stayed big (strong). It caused an immense amount of **** because we had to add a 10K pullup resistor. You would think the world came to an end! The wailing, the nashing of teeth .... you get the picture. --------------B8C7AD462CF21207EA77122C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Hal, <p>I will comment below. <p>Austin <p>Hal Murray wrote: <blockquote TYPE=CITE>[My initial msg.] <p>> > [Context is wanting to run a DLL at 24 MHz when the min spec is 25.] <br>> > <br>> > > Now, I am assuming you are not going below 0C, so there will be some <br>> > > margin there. But if not, then definitely don't do it. <br>> > <br>> > In general, CMOS prop time is linear in temp and supply voltage. He's <br>> > only off by 4% so we should be able to draw the forbidden zone on a graph <br>> > with voltage on one axis and temp on the other. <br>> > <br>> > Does that sort of reasoning work with DLLs? <br>> > <p>In article <3A561466.534B42DB@xilinx.com>, <br> Austin Lesea <austin.lesea@xilinx.com> writes: <br>> Hal, <br>> <br>> Yes. <br>> <br>> I just can't say "go ahead" for all of the reasons I stated. Someday, some <br>> lot might be just a little too fast (even though it is pretty unlikely). <p>That's exactly the point I was trying to make. Why can't you say "go ahead"? <br>Is there a flaw in my reasoning or is that due to legal issues?</blockquote> <i>There is an implicit contract here. We state in the specifications that the product will do X. If it doesn't do X, you get it replaced with one that does.</i> <blockquote TYPE=CITE> <p>In most interesting projects, a designer has to use a lot of information <br>that isn't in the data sheet. What's the "contract" between the vendor <br>and the designer? How can I be sure that a design will work correctly <br>if I use information from app notes or general common sense or rumors <br>from usenet?</blockquote> <i>Spec sheet = contract. App note = we will support it just like the spec sheet. A email from a Xilinx engineer is a written document, so it also must be treated as a statement of 'suitablity for use' ... ie we would have to supply chips that do what was said. Thus, my caution. Anything else, well, have fun.</i> <blockquote TYPE=CITE> <p>Note that there are two types of extra information. One is things like <br>how to get the tools to do what you want or explainations of what a <br>particular line on the data sheet really means. <p>The other type of information is extra - things you won't find in the <br>data sheet at all. The obvious example is speed being linear with <br>temperature and VCC.</blockquote> <i>True. There are a lot of implicit assumptions engineers make everday. I did it for 20 years in telecom, and I still have to do it now. Sometimes the common knowledge isn't all that common, and it may not be true (e.g. maybe there is temperature compensation in the circuit, and it isn't getting faster as it gets colder, or there is a voltage regulator hidden on chip that we don't talk about). Usually a phone call, or an email will clear up little things like that. That is what this question was all about -- is there any reason why one shouldn't use it at 24 MHz? I went around, and unanimously everyone said "no problem," but then I asked OK, so then why don't we change the spec? No takers. 0, Nada. So, if the spec won't change, I can not recommend its use -- for all of thereasons stated.</i> <blockquote TYPE=CITE> <p>In this context, I guess that some of the tools are part of the contract, <br>next to the data sheet. I'm thinking of the timing verifier or report <br>generator and the power estimator.</blockquote> <i>Yes.</i> <blockquote TYPE=CITE> <p>The particular case that I proposed is tricky because it depends upon <br>minimum prop times and the general party line is things might go faster. <p>But in this particular case, there is a requirement for that min in the <br>spec sheet. The spec sheet says it will work down to 25 MHz. <p>Most people know it's "legal" to reduce the prop times in a data sheet <br>if you can keep a part cool and/or keep the VCC above min. My proposal <br>uses the same approach, just with the reverse sign bit. If it will <br>work at 25 MHz at max VCC, will it run at 24 MHz if I keep VCC at least <br>5% below max?</blockquote> <i>OK. Now that is a good question. If you kept the Vccint below the recommended maximum limit by 5%, you have gained some margin. If you additionally never go below 10 C (an asian indoor telecom limit -- it never really gets cold in Taiwan or Hong Kong), they you have some more margin.</i><i></i> <p><i>But remember the comments about the possibility of a hidden voltage regulator, and temperature compensation? Maybe the margin gained isn't all that much.</i> <blockquote TYPE=CITE> <p>-- <br>These are my opinions, not necessarily my employers. I hate spam.</blockquote> <p><br><i>What I would do, if there was a clear reason to do this (save a ton of money, or make the board smaller, or ...) is to take apart, find the low frequency limit, and then change the voltage, and change the temperature, and see how it changes. I'll save you some of the work: the voltage is regulated for part of the circuit, so it won't get as fast as expected with voltage. There was also a lot of work on removing temperature sensitivity, but it is still there. The DLL will get faster as it gets colder, but not faster as fast as the core logic.</i><i></i> <p><i>Then, I would see what my margin is. If I have a 2X margin, then I would probably just go to it, and be done with it (standard engineering derating). If my margin was only 50%, then I probably still would go ahead, as it would take a lot of process changes, and perhaps even design changes to eat that up -- but I could never be sure. I might put in place an incoming inspection, and I might ask for a letter from my distributor to inform me of any change to the process on that part (a standard service for customers).</i> <p><i>I always got that letter in my telecom job, because in telecom, if anything changes, it scares the hell out of the phone companies. They have only been in business for 130+ years, so they know that change = bad in any design. Changes in components required an immediate re-qualification of the product, regardless of the change (unless it was the ink on the top, or some other silly change).</i><i></i> <p><i>When Matra changed the 80C31 (did a shrink for yield and cost), they shrank a transistor pullup that should have stayed big (strong). It caused an immense amount of **** because we had to add a 10K pullup resistor. You would think the world came to an end! The wailing, the nashing of teeth .... you get the picture.</i> <br> </html> --------------B8C7AD462CF21207EA77122C--Article: 28440
Sven Fleck wrote: > > Hi there, > > can anybody give me good references for stereo vision algorithms which are > best suited for the parallel execution nature of FPGAs to better solve the > correspondence problem using a correlation based approach? I know about the > CMU group using DSPs and so on, but FPGA designs are rather hard to find, > but should in my eyes be far superior in performance. There was some work made by the Perle-1 team 6 or 7 years ago on the early xc3000 series (authors were O.Faugeras and J.Vuillemin). I'm not aware of recent work with FPGA on this field. Olivier Faugeras et al. Real time correlation-based stereo: algorithm, implementations and application, http://www-sop.inria.fr/robotvis/personnel/faugeras/publications.html The thing is that there would be no reason (except power consumption) to implement correlation based approach in an FGPA since you can already get real-time in sowtware with recent CPUs or DSPs... > (small overview is included in Kurt Konolige's "Extra-Pair-Of-Eyes" > DSP-design) > > I would like to use a Xilinx Virtex-1000 board running @ 100MHz for this > task. You wouldn't need such a huge Virtex to do that ! An xcv300 should be enough (operation are on 8 to 12 bits with almost no multiplications !) Steven > > Thanks in advance! > > Sincerely, > > Sven Fleck > > ---------------------------------- > Sven Fleck > University of Tuebingen > GermanyArticle: 28441
"Sven Fleck" <fleck@informatik.uni-tuebingen.de> wrote in message news:93n834$14d$1@newsserv.zdv.uni-tuebingen.de... > Hi there, > > can anybody give me good references for stereo vision algorithms which are > best suited for the parallel execution nature of FPGAs to better solve the > correspondence problem using a correlation based approach? I don't know what the correspondence problem is, but have you seen Woodfill and Von Herzen's paper "Real Time Stereo Vision on the PARTS Reconfigurable Computer" [http://www.fpga.com/papers/stereovis.pdf]? "The first application implemented on the PARTS engine is a depth from stereo vision algorithm that computes 24 stereo disparities on 320 by 240 pixel images at 42 frames per second. Running at this speed, the engine is performing approximately 2.3 billion RISC-equivalent operations per second, accessing memory at a rate of 500 million bytes per second and attaining throughput of over 70 million point x disparity measurements per second. " Jan Gray, Gray Research LLCArticle: 28442
--------------D862F087FDE4A8FCACC3AC41 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit I wrote an app note on the subject. You can click on http://www.xilinx.com/xapp/xapp092.pdf Peter Alfke, Xilinx Applications ====================================== Simon Fielder wrote: > Thankyou for any help. > > Please could someone point me to the relevant information on the folowing subjects. > > 1) What does the basic FPGA SRAM cell or element look like? A description of how it is constructed (to the component level - transistors, resistors etc.) and a diagram of a single cell (does it look like a six transistor SRAM memory cell or does it differ?) would be very useful. > > 2) Has any failure analysis been carried out on the SRAM elements themselves and if so where can I get the results please? Has anyone any useful information on failures of the SRAM cells? > > 3) What is the effectiveness of the engineering and stability of programming configuration. For example if an SRAM FPGA is left powered but unused for a period of time, say a few weeks, at the end of this period would the SRAM element, and hence the FPGA itself, still be exactly as it was when originally programmed? > > Thankyou. --------------D862F087FDE4A8FCACC3AC41 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> I wrote an app note on the subject. You can click on <p><u><A HREF="http://www.xilinx.com/xapp/xapp092.pdf">http://www.xilinx.com/xapp/xapp092.pdf</A></u> <p>Peter Alfke, Xilinx Applications <br>====================================== <br>Simon Fielder wrote: <blockquote TYPE=CITE>Thankyou for any help. <p>Please could someone point me to the relevant information on the folowing subjects. <p>1) What does the basic FPGA SRAM cell or element look like? A description of how it is constructed (to the component level - transistors, resistors etc.) and a diagram of a single cell (does it look like a six transistor SRAM memory cell or does it differ?) would be very useful. <p>2) Has any failure analysis been carried out on the SRAM elements themselves and if so where can I get the results please? Has anyone any useful information on failures of the SRAM cells? <p>3) What is the effectiveness of the engineering and stability of programming configuration. For example if an SRAM FPGA is left powered but unused for a period of time, say a few weeks, at the end of this period would the SRAM element, and hence the FPGA itself, still be exactly as it was when originally programmed? <p>Thankyou.</blockquote> </html> --------------D862F087FDE4A8FCACC3AC41--Article: 28443
The answer is no, if your hookup is as fig 23 in AN116. In this hookup, the multiple FPGAs look (to the uP) like a single huge FPGA. FPGA #1 (first in the string) inhibits its nCEO output until it is programmed, so that FPGA #2 (and successive FPGAs) are simply waiting and doing nothing. When FPGA #1 is programmed, its nCEO output is asserted, and FPGA #2 then starts responding to the data strobes. When FPGA #2 is programmed, its nCEO output is then asserted, allowing the next successive FPGA to program, etc. etc. until the whole chain is configured. I personally prefer to avoid the daisy chain mode of programming, because it is more difficult to debug in case of failure. An intermediate approach is to bring each of the nSTATUS and CONFIG_DONE lines to the uP, without bussing them together. This gives the uP a clear picture of which FPGA is programmed (or not), or generated an error. Cheers, Bob Elkind, eteam@aracnet.com Meta Fernando wrote: > > I have to configure 3 APEX20K1500 by a Flash memory controller. > I chosen a PPA scheme for the configuration (Doc. : Altera AN116) > My questions is: > > After first device's configuration... > - Do I have to move again the signals nCONFIG, nCS and CS for the second > and the third device? > > Thanks in advance!Article: 28444
On Thu, 11 Jan 2001 17:06:31 +0100, Christian Wiencke <christian.wiencke@stud.uni-rostock.de> wrote: ><!doctype html public "-//w3c//dtd html 4.0 transitional//en"> ><html> >Hi, ><br>I'm using a Block SelectRAM in a VirtexE Design. During the timing >simulation with Synopsys VHDL Debugger (version 1999-10) I get the following >warning: ><p>Assertion WARNING at ... in design unit VPACKAGE from ... "Invalid ADDRESS: >0101010101. Memory contents will be set to 'X'." ><p>The address, data, enable and write enbalbe signals are correct, but >the simulation produces this assertion. I had a look at the SIMPRIM model >of the BlockRAM. There is a function ADDR_IS_VALID, which checks for the >validity of the argument. ><p><font face="Courier New,Courier"><font size=-1> function ADDR_IS_VALID >(</font></font> ><br><font face="Courier New,Courier"><font size=-1> >SLV : in std_logic_vector</font></font> ><br><font face="Courier New,Courier"><font size=-1> ) return boolean >is</font></font> ><br><font face="Courier New,Courier"><font size=-1> </font></font> ><br><font face="Courier New,Courier"><font size=-1> variable IS_VALID >: boolean := TRUE;</font></font> ><br><font face="Courier New,Courier"><font size=-1> </font></font> ><br><font face="Courier New,Courier"><font size=-1> begin</font></font> ><br><font face="Courier New,Courier"><font size=-1> >for I in SLV'high downto SLV'low loop</font></font> ><br><font face="Courier New,Courier"><font size=-1> >if (SLV(I) /= '0' AND SLV(I) /= '1') then</font></font> ><br><font face="Courier New,Courier"><font size=-1> >IS_VALID := FALSE;</font></font> ><br><font face="Courier New,Courier"><font size=-1> >end if;</font></font> ><br><font face="Courier New,Courier"><font size=-1> >end loop;</font></font> ><br><font face="Courier New,Courier"><font size=-1> >return IS_VALID;</font></font> ><br><font face="Courier New,Courier"><font size=-1> end ADDR_IS_VALID;</font></font> ><p>The address (SLV) is "0101010101", but the function generates FALSE. >Is it a bug in the simulation software? ><br>Do you know this problem? ><p>Thanks ><br>Christian</html> > really hate it when people post in HTML crap. Ralph Watson Return Email Address is: ralphwat dot home at excite dot com just type the address in like it should look likeArticle: 28445
In article <TCb56.8725$4c.743972@ruti.visi.com>, amolitor-at@visi-dot-com.com wrote: > In article <3A552F9E.61B88CDB@igs.net>, Paul DeMone <pdemone@igs.net> wrote: > >What exactly do you mean? An FSM with probablistic state transitions > >governed by a pseudo random sequence generator like an LFSR or a linear > >congruence modulo multiplier? Or governed by a truely random noise > >source like amplified thermal background noise? > > _Compilers:_Principles,_Techniques,_and_Tools_ > discusses this. What you do with an NFA is that you essentially > "take" all the transitions that are possible in a state, > at once. > > Your current "state" is really the set of all the states > of the NFA (Non-deterministic Finite Automaton) that you could > be in. You take all the possible transitions out of all those > states that you could be in. I think if one of the new > states is a terminating state, you stop. From a different point of view, all this comes across as very much like "quantizing" traditional FSMs. Recall that to quantize a classical "system", you construct the free complex vector space over the state space of the classical system, ie the elements, |psi> of your quantized theory are vectors associating a complex number with every possible state of of the underlying classical system. You then define some linear scheme for these states to evolve which is trivially defined by the underlying FSM. The only real difference would appear to be that the NFA is filling that vector with 1s and 0s rather than complex numbers. Obviously this works well for simulation and hardware construction. For more general discussion of mathematical properties, the more general free complex vector space (with 0 treated as 0 and non-zero treated as 1 at the end of the day) may be more powerful. Maynard > You can implement these things pretty efficiently (for > a fixed maximum number of states) by managing your current state > as a bit-vector which indicates which of the NFA states you > are currently in. > > You should be able to, um, use the current bit vector as > enables on a set of functional units (one per state) each of > which consumes the current input symbol and emits a new > bit vector of possible states. Then OR the results of all > the functional units together to get your new state. And the > current state vector with a vector representing terminating > states, if the result is non-zero, stop. > > Your hardware will set a Really Hard cap on the maximum > number of NFA states you support. The details of how input symbols > select transitions will determine the inner structure of the > functional units. If, for eaxmple, you are doing string matching, > there is a straightforward way to convert a regular expression into an > NFA. If you support up to, say, 64 states (which will capture regular > expressions up to something near 64 characters long, I think), each > state (functional unit) can be a 256 element memory 64 bits wide. The > input symbol is a character, and acts as the address. Address all > the little RAMs at once, and use the current input state as output > enables on the RAMs. This could go quite fast, though where you'd > find RAMs that shape I have no idea. I guess you could do this in > an FPGA and do regexp matching at 100M characters/second? Network > Intrusion Detection, anyone? > > Why I don't get is what makes this interesting, > it all seems pretty trivial to me. Am I missing something? > > A previous poster basically summed it up. You implement > an NFA as a DFA (Deterministic Finite Automaton) whose states are > collections of the NFA state. The point of doing it as an NFA is > that you don't have to construct the entire DFA, you essentially > "dynamically" construct that states and transitions of an equivalent > DFA as you go. The NFA is generally quite a bit smaller than equivalent > DFAs (I think one can construct examples where equivalent DFAs all have > 2^n states). Furthermore, if you need to run a finite automaton on one > input only, it is more efficient to run the NFA and (inefficiently) > construct only the DFA states you NEED instead of constructing the > entire DFA. > > > The referenced book has a nice discussion of many of these issues. > > [ by the way, I forget, or never knew, whether one NFA can have > more than one equivalent DFA. I used the plural above, because > it feels right, but there may always be one DFA ]Article: 28446
arast@inficom.com (Alex Rast) writes:
> If you look at the output of the cable with a scope, none of the JTAG lines
> ever see data on them. I'm suspicious we may have a bad cable, but are there
> other possibilities? Is there some oddball software incompatibility? Strange
> idisyncracies in the XC95144?
I've configured the XC95144 by generating a svf file under solaris
using jtagprog, then transfer the svf file to a PC with software and
jtag supporting hardware from JTAG Technologies. I can't seem to
remember any XC95144 idisyncracies...
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}
Article: 28447
We apologize for multiple mailings. -Christof Paar
===================================================================
WORKSHOP ON CRYPTOGRAPHIC HARDWARE AND EMBEDDED SYSTEMS
(CHES 2001)
www.chesworkshop.org
Paris - France
May 13 - 16, 2001
Second Call for Papers
General Information
The focus of this workshop is on all aspects of cryptographic
hardware and embedded system design. The workshop will be a forum of
new results from the research community as well as from the industry.
Of special interest are contributions that describe new methods for
efficient hardware implementations and high-speed software for
embedded systems, e.g., smart cards, microprocessors, DSPs, etc. We
hope that the workshop will help to fill the gap between the
cryptography research community and the application areas of
cryptography. Consequently, we encourage submission from academia,
industry, and other organizations. All submitted papers will be
reviewed.
This will be the third CHES workshop. The first workshop, CHES '99,
was held at WPI in August of 1999 and was very well received by
academia and industry. There were 170 participants, more than half of
which were from outside the United States. The second workshop, CHES
2000, was also held at WPI in August of 2000 and had an attendance of
180.
The third workshop, CHES 2001, will be held in Paris in May of 2001.
The topics of interest include but are not limited to:
* Computer architectures for public-key cryptosystems
* Computer architectures for secret-key cryptosystems
* Reconfigurable computing and applications in cryptography
* Cryptographic processors and co-processors
* Modular and Galois field arithmetic architectures
* Tamper resistance on the chip and board level
* Smart card attacks and architectures
* Efficient algorithms for embedded processors
* Special-purpose hardware for cryptanalysis
* Fast network encryption
* True and pseudo random number generators
* Cryptography in wireless applications
Instructions for Authors
Authors are invited to submit original papers. The preferred
submission form is by electronic mail to submission@chesworkshop.org.
Papers should be formatted in 12pt type and not exceed 12 pages (not
including the title page and the bibliography). The title page should
contain the author's name, address (including email address and an
indication of the corresponding author), an abstract, and a small
list of key words. Please submit the paper in Postscript or PDF. We
recommend that you generate the PS or PDF file using LaTeX, however,
MS Word is also acceptable. All submissions will be refereed.
Only original research contributions will be considered. Submissions
must not substantially duplicate work that any of the authors have
published elsewhere or have submitted in parallel to any other
conferences or workshops that have proceedings.
Important Dates
Submission Deadline: February 15th, 2001.
Acceptance Notification: March 31st, 2001.
Final Version due: April 21st, 2001.
Workshop: May 13th - 16th, 2001.
NOTE: The CHES dates May 13th - 16th are the Sunday - Wednesday
succeeding Eurocrypt 2001 which ends on Thursday, May 10th.
Mailing List
If you want to receive emails with subsequent Call for Papers and
registration information, please send a brief mail to:
mailinglist@chesworkshop.org
Invited Speakers
Ross Anderson, University of Cambridge, U.K.
Protecting Embedded Systems - the Next Ten Years
Program Committee
Ross Anderson, University of Cambridge, England
Jean-Sebastien Coron, Gemplus, France
Kris Gaj, George Mason University, USA
Jim Goodman, Chrysalis-ITS, Canada
Anwar Hasan, University of Waterloo, Canada
Peter Kornerup, Odense University, Denmark
Bart Preneel, Katholieke Universiteit Leuven, Belgium
Jean-Jacques Quisquater, Universite Catholique de Louvain, Belgium
Christoph Ruland, University of Siegen, Germany
Erkay Savas, cv cryptovision, Germany
Joseph Silverman, Brown University and NTRU Cryptosystems, Inc., USA
Jacques Stern, Ecole Normale Superieure, France
Colin Walter, Computation Department - UMIST, U.K.
Michael Wiener, Entrust Technologies, Canada
Organizational Committee
All correspondence and/or questions should be directed to either of the
Organizational Committee Members:
Cetin Kaya Koc
(Publications Chair)
Dept. of Electrical & Computer Engineering
Oregon State University
Corvallis, Oregon 97331, USA
Phone: +1 541 737 4853
Fax: +1 541 737 8377
Email: Koc@ece.orst.edu
David Naccache
(Program Chair and Local Organization)
Gemplus Card International
34 Rue Guynemer
92447 Issy les Moulineaux Cedex, FRANCE
Phone: +33 1 46 48 20 11
Fax: +33 1 46 48 20 04
Email: David.Naccache@gemplus.com
Christof Paar
(Publicity Chair)
Dept. of Electrical & Computer Engineering
Worcester Polytechnic Institute
Worcester, MA 01609, USA
Phone: +1 508 831 5061
Fax: +1 508 831 5491
Email: christof@ece.wpi.edu
Workshop Proceedings
The post-proceedings will be published in Springer-Verlag's Lecture
Notes in Computer Science (LNCS) series. Notice that in order to be
included in the proceedings, the authors of an accepted paper must
guarantee to present their contribution at the workshop.
Article: 28448On Fri, 12 Jan 2001 09:48:07 -0500, "Jamie Sanderson" <jamie@nortelnetworks.com> wrote: >I guess what I thought was a clear question really wasn't, since I've had a >number of responses which didn't address the issue. (not that I don't >appreciate the effort) > >I think it would be illuminating if I posted an example of Jan's code. To >keep it short, I used the polynomial from E1, which is a CRC-4 with a >generating polynomial of x^4 + x + 1, calculated over a byte. > >Looking at the code below, you'll find that it contains a set of four XOR >statements which compute successive values of the CRC. What I don't >understand is how these statements were generated. Clearly there is an >algorithm for doing this since Jan's tool obviously makes use of one. I'd >like to know what that is (assuming it's not proprietary). This is exactly what a parallel factorisation is. Assume you've got 8 serial data bits going into a 4-bit LFSR. When you put in the 1st bit, you get 4 equations for the next state of the LFSR. Iterate 7 more times, for the remaining data bits, using the new values of the LFSR, and the last set of 4 equations is the result; these define the value of each bit of the LFSR after an entire byte is shifted in. You'll find that there are lots of common terms, and you can factorise them out. Eventually, you'll end up with lots of XORs, to give you a parallel implementation of the CRC. The TAXI app note covers it all if you can find it. EvanArticle: 28449
Jamie Lokier wrote: > > Andy Peters writes: > > ModelSim and Synplify both use dongles (which I vastly prefer over > > that FlexLM bogosity) but the Mac ain't got a parallel port so I'm SOL > > there. > > And even if the MAC did have a parallel port... > > I vastly prefer FlexLM because there is some hope of it working in an > emulator. In my experience dongle reading code does seriously weird > things to your parallel port, and doesn't work in an emulator. Yeah, but if FlexLM is keyed to your ethernet MAC (not Macintosh!) address and you want to, say, do some work at home, you're hosed. And when you get a new computer with a new ethernet card (or your card dies), you have to deal with getting a new license file, which isn't difficult, but it IS annoying. Here's my thought on all this: choose the software, and buy whatever OS and machine it runs on, rather than buying (or downloading) an OS and installing it on a particular machine and using hacks and such in an effort to get the software to work on it. Yes, I'd like ModelSim PE and the Xilinx tools and Synplify to all run on Linux. But my job is to design FPGAs, and if that requires running NT, so be it. Yes, I will tell the vendors that I prefer Linux. Yes, I will demand that the Linux versions of the tools cost the same as the NT versions. No, I will not frustrate myself trying to get software written for one OS to run on another. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt."
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