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
Rick Filipkiewicz <rick@algor.co.uk> wrote in message news:<3CE62C87.9C4C83FE@algor.co.uk>... > Hal Murray wrote: > > > >I think this is possible if the ratio of portA/portB is a root of 2. > > >Because, the port size on brams is in power of 2. > > >Therefore, it works in case of 128(wider port)/32(narrower port) = 4 > > >(# of brams). i.e. scramble the 96bits in groups of 32(narrower > > >port)/4(# of brams) = 8 bits. > > > > > >In my case, (portA = 96)/(portB = 32) = 3. This will not work without > > >going through some hassle which I think will be more than using a mux > > >or tristate bufs. > > > > I don't know how this fits into your tradeoffs, but I think you > > can make Peter's suggestion work if you are willing to throw away > > 1/4 of your memory. > > > > Write 4x32 bits. Put garbage or a constant in the top word. > > When reading, read words 0, 1, 2, but skip over word 3. > > Well, that is essentially, what I am doing. I do not even have to hook up the 4th block ram. To keep it convenient the words are aligned to 128b. Although, I only use 96b. And therefore, I do not really, have the need for the 4th block ram. But even if I had a 4th block ram, I cannot scramble the bits using the 4th block ram. > > In that case what we would have for the read side is: > > BRAM address = read_addr / 3 > > BRAM select = read_addr % 3 > > Maybe I'm thinking of the case where the read address is random though. If > reading is always sequential then its easy. > > Another approach, if there are 2 clocks available for each write, might be to use > a 64 bit wide input port: > > input address 0 -> ram address = 0: words 0, 1 > ram address = 1: word 2 into lower > > input address 1 -> ram address = 1: word 0 into upper > ram address = 2: words 1,2 > > Then the pattern repeats. For each even/odd pair of input addresses the first ram > address is > > 3 * (input address/2) > > which can be done either via a lookup table or the Virtex-2 h/w multiplier. > > This approach would be less costly if the input went 128/256 bits wide since then > a 2 clock write is needed only on 1/2 or 1/4 of the incoming writes. > > Note that if not enough clocks are available at the input speed you could always > use a DCM to generate a x2 clock (or x1.5 @128 bits or ...). This certainly seems like a way to solve the problem. But I am not sure why this would be better than using a mux or a tristate buffer? Not having worked with xilinx devices for long I may not know something that is obvious to or known by more experienced.Article: 43301
In article <3CE68609.658424F0@attbi.com>, Phil Hays <SpamPostmaster@attbi.com> wrote: >So? A complete test isn't practical. For example, look at the small >switch box on the output of a CLB. Notice that each of the 8 outputs >from this switch box can be programmed to one of 12 sources. The number >of legal combinations is somewhat more than (12*12*12... eight times) or >12^8 or 429,981,696 different ways to program that switch box. At 25 ms >per configuration load, all combinations could be verified in somewhat >more than 124 days. The larger switch boxes would take rather longer. >A check for interactions between switch boxes much longer still. You >simply can't do a complete test, even if you wanted to. Why do you think Xilinx SUPPORTS partial reconfiguration? That hardware wasn't included for the users, but for the test engineers. I'd personally bet that there are some nice "Reconfigure ALL slices to the same config" option too, to really speed up testing. >A shorter than complete test needs to make assumptions that may well be >very good, but may well miss specific failures. Understand, I'm not >looking for perfection. I'm looking for a better test. I'd like to buy >it as an off the shelf option, if I could. I'd rather buy it from >Xilinx, but if not there are other options such as a third party test >house and/or do it in house. But what probablity do those failures occur: EG, two WEAK transistors (instead of dead transistors) which would affect a critical path on one configuration? ALso, remember, NOTHING is certain, 100%, in the electronics world: by the same argument, that CPU you rely on can always be hit by a gamma ray on one of the internal busses. You have to settle with some very low probablity of failure (which can be made arbitrarily low by various schemes), but is still finite. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 43302
> > > Write 4x32 bits. Put garbage or a constant in the top word. > > > When reading, read words 0, 1, 2, but skip over word 3. > > > > Well, that is essentially, what I am doing. I do not even have to > hook up the 4th block ram. To keep it convenient the words are > aligned to 128b. Although, I only use 96b. And therefore, I do not > really, have the need for the 4th block ram. But even if I had a 4th > block ram, I cannot scramble the bits using the 4th block ram. If you have 4 RAMs, and you interlace the write bits, then you can use the muxing in the RAM by reading each RAM 8 bits wide rather than 32. [I think that's what Peter was suggesting.] -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 43303
Are you going to drive the DAC with a clock signal from your DLL? You can just use different phase shifted signals until it works and you meet your setup requirements. I would guess either a 180 degree or 270 degree phase shift would work. adrianArticle: 43304
shparekh@yahoo.com wrote: > Rick Filipkiewicz <rick@algor.co.uk> wrote in message <snip> > > > This approach would be less costly if the input went 128/256 bits wide since then > > a 2 clock writming writes. > > > > Note that if not enough clocks are available at the input speed you could always > > use a DCM to generate a x2 clock (or x1.5 @128 bits or ...). > > This certainly seems like a way to solve the problem. But I am not > sure why this would be better than using a mux or a tristate buffer? > Not having worked with xilinx devices for long I may not know > something that is obvious to or known by more experienced. No its my apology time since I missed out one important thing about the BRAMs. The A & B ports can be configured with different widths! For example if the `A' port is set up to 2Kx9 then the `B' port can be 2Kx9 [1:1] 1Kx18 [2:1] or 512x36 [4:1] => no mux is needed as long as 4 BRAMs [16KB] satisfy your storage needs. Other combinations are possible - see Table 15 in the V-2 manual BRAM section.Article: 43305
Hi, Could anyone point me to a reference on fanning out signals to multiple FPGA's. I want to fan out 2x6bit signals to seven Spartan II's at 32MHz, but my ADC from where the signals are being fanned from can only source up to 20mA. Anyone have any ideas? What kind of current will a Spartan II draw per pin? thanks adrianArticle: 43306
I have a board with a VirtexE on it and with amongst other things, a button
(call it USER_IN) and three leds (call then LED[2:0]) controlled by a
variable lstate. I want to create a modest state machine so that I
initialize lstate to 3'b000, and then with each button push, I move to
3'b001..3'b111 and then back to 3'b000. I tried the following:
always @(posedge clk and USER_IN)
begin
lstate = lstate + 1;
end
But what seems to happen is the states are cycling through at clk speed. The
reason I could not use (posedge clk and posedge USER_IN) is then the Xilinx
ISE wants to assign USER_IN to a clock pin and I cannot implement the
design. Maybe this issue is my understanding of ISE and Verilog as I am
officially a newbie at this time.
Next I tried
always @(posedge clk and USER_IN)
begin: ledstater
reg lstate_toggle;
if(USER_IN & lstate)
begin
lstate_toggle = !lstate_toggle;
lstate = lstate + 1;
end
end
This one doesn't seem to do anything to the LED's (which are set with a
seperate assign statement). So, any suggestions would be greatly
appreciated.
Charles
Article: 43307Kevin Brace wrote: > > > Here is how I solved the problem. > I decided to install WebPACK ISE 3.3 (Now it is called ISE WebPACK, but > I guess it doesn't matter.) which also comes with XST to my computer > where I already got ISE WebPACK 4.2. > I read some time ago that XST with WebPACK ISE 3.3 generates an EDIF > file instead of an encrypted .NGC file (The XST since ISE 4.1 does so, > unfortunately.), so I will manually edit the netlist to duplicate FFs. > The result is, when I tested it, NGDBUILD correctly read my PCI IP core > in a netlist, and MAP correctly pushed FFs I duplicated by hand into > IOBs. > The only problem is, it takes about 2 to 3 hours to duplicate all 95 or > so FFs by hand, using a text editor, but that's much better than not > being able to edit an encrypted netlist (.NGC file) at all. > I really and truely don't understand the decision to change from an ``industry standard'' format - i.e. EDIF - to a binary [and encrypted ?] one esp. as all the 3rd party tools output EDIF so NGDBUILD is always going to have to be able to handle it. The only thing I can come up with is the possibility that someone somewhere might write a ``technology retargeting'' tool and thus gain a free synthesiser for their architecture. However the EDIF file has a lot of technology optimisations specific to Xilinx [and even to a particular Xilinx device *family* ] built in so I'd say the QOR from this process wouldn't show the other technology in a very good light unless it was architecturally very close to Xilinx's ... at which point synth tools would be irrelevant as the case would already be in the hands of the patent lawyers. Anyone from Xilinx prepared to confirm that this is the reason ?Article: 43308
Hi, I'm improving the design of a Xilinx 4062XLA BG432 device. It is running at 50Mhz, and I try to do the following 4 stage logic in 1 cycle: 4 bit adder 4-1 mux 32 bit wide, 16 deep dual port ram 4-1 mux Can I make it? ThanksArticle: 43309
I mean the first stage is 4 bit adder (no overflow bit is needed) 2nd stage is 4-1 MUX 3rd stage is 32 bit wide, 16 deep DPRAM (block ram), 4th stage is another 4-1MUX. Can I do it? ThanksArticle: 43310
Actually, I have a similar need, so let me pose the original posters question in a different way. It is sometimes necessary to have user logic initialize in a known state from power up. Perhaps the GSR signal might be more appropriate (I can see it used in some modules in unisim), but so far, I have been unable to get past "unresolved reference to GSR or glbl.GSR" either in my ISE or Modelsim. I have tried compiling glbl.v in (I am working in verilog) to no avail. So, how does one find a way to let some user code run once?? Charles "Austin Lesea" <austin.lesea@xilinx.com> wrote in message news:3CE3D32C.1F877C05@xilinx.com... > Stephanie, > > Internally, when in chains of FPGAs, the DONE pin of the master waits to > see the DONE pin of the last slave go high (hence it is an input in that > mode). > > Basically, no user logic can operate until DONE goes high, so I don't see > why you need this. As soon as DONE goes high, all initial register > values, FF states, BRAM contents, etc are all present, and on the next > user supplied system logic clock, everything starts marching along. > > Austin > > Stephanie McBader wrote: > > > Hi, > > > > Xilinx FPGA datasheets (both Virtex & Spartan) indicate that the DONE > > pin is bidirectional. Does that mean that the logic configured inside > > the FPGA will be able to read it? > > > > i.e., would a controller implemented in the FPGA be able to read the > > value of DONE & say, remains in reset until DONE is asserted? > > > > Thanks! > > > > Stephanie McBader > > Researcher/Design Engineer > > NeuriCam S.p.A > > Via S M Maddalena 12 > > 38100 Trento TN, Italy > > Tel: +39-0461-260552 > > Fax: +39-0461-260617 >Article: 43311
Nicholas Weaver wrote: > In article <3CE68609.658424F0@attbi.com>, > Phil Hays <SpamPostmaster@attbi.com> wrote: >> So? A complete test isn't practical. > I'd personally bet that there are some nice "Reconfigure ALL slices to > the same config" option too, to really speed up testing. An interesting speculation, however it doesn't change the issue much. The tiny output switch box might be tested faster by several orders of magnitude by such methods, but Xilinx can't afford to spend more a day testing just that part of the device, or even a hour. Tester time on big part testers isn't cheap: fifteen years ago we figured on about US$ 0.25 per second, and while I've been out of that end of the business since then I doubt if it has gotten cheaper. The output switch box is much smaller, meaning much easier to test, than the input switch box or the routing switch box. To fully test the interaction between switch boxes is probably longer than the age of the Universe. > >A shorter than complete test needs to make assumptions that may well be > >very good, but may well miss specific failures. Understand, I'm not > >looking for perfection. I'm looking for a better test. I'd like to buy > >it as an off the shelf option, if I could. I'd rather buy it from > >Xilinx, but if not there are other options such as a third party test > >house and/or do it in house. > > But what probablity do those failures occur: EG, two WEAK transistors > (instead of dead transistors) which would affect a critical path on > one configuration? Josh's estimate from last year was about 1 in 50 parts had an undetected defect. http://groups.google.com/groups?hl=en&lr=&selm 010731.103308.1239036029.24248%40polybus.com The parts in question are of similar manufacturing date. > ALso, remember, NOTHING is certain, 100%, in the electronics world: by > the same argument, that CPU you rely on can always be hit by a gamma > ray on one of the internal busses. You have to settle with some very > low probablity of failure (which can be made arbitrarily low by > various schemes), but is still finite. I'm not looking for certainty, I'm looking for better odds. The probability of failure can be lowered by getting a more complete test, which probably does not make economic sense for the majority of users. -- Phil HaysArticle: 43312
Current is not the issue. At a guaraneted max input current of 10 microamps, you could drive a fan-out of twothousand! Delay is the issue. How much capacitance are you driving? For a very rough approximation assume each input to be 10 pF, double or triple that for the pc-board traces, and assume a 20 Ohm output impedance. At seven loads times 40 pF, you get a time constant of 5.6 ns ( very pessimistically). This ignores signal integrity issues like reflections etc. Can you live with a 5 to 10 ns delay? Peter Alfke, Xilinx Applications. =================== Adrian wrote: > Hi, > > Could anyone point me to a reference on fanning out signals to multiple FPGA's. I want to fan out 2x6bit signals to seven Spartan II's at 32MHz, but my ADC from where the signals are being fanned from can only source up to 20mA. > > Anyone have any ideas? What kind of current will a Spartan II draw per pin? > > thanks > adrianArticle: 43313
On Thu, 16 May 2002 20:45:53 -0600, rickman wrote: > you need to design in a level of programmable interconnect that may make > the problem a bit more complex. What about using the FPGA's existing interconnect, and changing the connections betweeen neurons using partial reconfiguration?Article: 43315
Rick Filipkiewicz wrote:
>
>
> I really and truely don't understand the decision to change from an
> ``industry standard'' format - i.e. EDIF - to a binary [and encrypted ?] one
> esp. as all the 3rd party tools output EDIF so NGDBUILD is always going to
> have to be able to handle it.
>
One problem of an encrypted netlist is that I cannot see if the
synthesis tool is correctly synthesizing the design.
Recently, I saw XST 'dropping' valid FFs used in a design.
It took me two days to figure out what was going on, and I found the
problem only when I synthesized the design with an old XST that
generated an EDIF netlist.
I can see that Xilinx wanting to have an encrypted netlist for
LogiCORE IP cores or COREgen IP cores because otherwise, users can
easily do an FPGA-to-ASIC conversion, but I feel like it is none of
Xilinx's business to restrict how I deal with a netlist generated by
XST.
> The only thing I can come up with is the possibility that someone somewhere
> might write a ``technology retargeting'' tool and thus gain a free
> synthesiser for their architecture. However the EDIF file has a lot of
> technology optimisations specific to Xilinx [and even to a particular Xilinx
> device *family* ] built in so I'd say the QOR from this process wouldn't
> show the other technology in a very good light unless it was architecturally
> very close to Xilinx's ... at which point synth tools would be irrelevant as
> the case would already be in the hands of the patent lawyers.
>
> Anyone from Xilinx prepared to confirm that this is the reason ?
Although I am not from Xilinx, one thing I noticed when I saw
the EDIF netlist generated by XST was that the primitives used by the
EDIF netlist looked like similar primitives that Altera's LUT-based
devices (i.e., FLEX, APEX, and Stratix) have.
I know that Altera devices don't have an F5MUX, but I think that can be
emulated with a regular 4-input LUT.
However, for about $10K, anyone can buy a synthesis tool (Synplify or
LeonardoSpectrum) that can generate an EDIF file that targets Xilinx or
Altera devices, so I am not sure if it makes much sense to create such a
conversion tool.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 43316
Mechanical switches bounce, meaning that there is not a clean 0 to 1 or 1 to 0
transition. Instead, the switch actually opens and closes hundreds of times
within a few milliseconds. A bouncing switch can make your state machine think
it is getting lots of button pushes within a short time, which, if observed on
the LEDs could give the illusion that the state machine is not stepping properly
when in fact it is (but going too fast to observe with your eyes).
In order to use a switch as an input to a logic circuit,the logic circuit needs
to include a switch debouncer, which is essentially a filter. A simple
debouncer can be made with a counter and a 4 state state machine:
case state is
s0:
reset counter
state<=s0 if switch=0, else s1
debounced out = 0
s1:
enable counter
state<=s0 if switch=0 else s1 if count_TC=0 else s2
debounced out = 0
s2:
reset counter
state<=s2 if switch=1 else s3
debounced out = 1
s3:
enable coutner
state<=s2 if switch=1 else s3 if count_TC=0 else s0
debounced out = 1
The counter should be long enough to not expire before the bounce time spec of
the switch (several milliseconds). For your state machine, you need to detect
the edge of the debounced switch signal (synchronous detection uses a flip-flop
to delay the debounced signal and a gate to sense when the debounced and
debounced delayed signals don't match). The edge detected signal can advance
your state machine. The debounce, edge detection and your state sequence can,
of course be combined into one state machine.
cfk wrote:
> I have a board with a VirtexE on it and with amongst other things, a button
> (call it USER_IN) and three leds (call then LED[2:0]) controlled by a
> variable lstate. I want to create a modest state machine so that I
> initialize lstate to 3'b000, and then with each button push, I move to
> 3'b001..3'b111 and then back to 3'b000. I tried the following:
>
> always @(posedge clk and USER_IN)
> begin
> lstate = lstate + 1;
> end
>
> But what seems to happen is the states are cycling through at clk speed. The
> reason I could not use (posedge clk and posedge USER_IN) is then the Xilinx
> ISE wants to assign USER_IN to a clock pin and I cannot implement the
> design. Maybe this issue is my understanding of ISE and Verilog as I am
> officially a newbie at this time.
>
> Next I tried
>
> always @(posedge clk and USER_IN)
> begin: ledstater
> reg lstate_toggle;
> if(USER_IN & lstate)
> begin
> lstate_toggle = !lstate_toggle;
> lstate = lstate + 1;
> end
> end
>
> This one doesn't seem to do anything to the LED's (which are set with a
> seperate assign statement). So, any suggestions would be greatly
> appreciated.
>
> Charles
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 43317>Actually, I have a similar need, so let me pose the original posters >question in a different way. It is sometimes necessary to have user logic >initialize in a known state from power up. Perhaps the GSR signal might be >more appropriate (I can see it used in some modules in unisim), but so far, This gets discussed here occasionally. An important thing to consider is that the timing on GSR is very slow. It's essentially an asynchronous signal. (Been there. Don't need another lesson.) Best suggestion is to have a local FF that gets reset by GSR and use it to reset your state machine. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 43318
Hal Murray wrote:
>
>
> That's the sort of response I got when I asked them where they
> got my email address. (I'm pretty sure they harvested it from
> here.)
>
> Anybody read/view the video? What company are they pushing?
> Anybody got any contacts in their marketing dept? ...
>
I got the same sapm you are talking about, so whoever idiot got
the E-mail addresses from this newsgroup.
I didn't feel like rewarding them by visiting their website, so I
immediately trashed the spam.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 43319
While I don't know if this the case here, a good reason for an encrypted netlist
is to protect IP. The open format of the EDIF netlist with no means of
encrypting it is a major hindrance to those wishing to sell IP.
Rick Filipkiewicz wrote:
> Kevin Brace wrote:
>
> >
> >
> > Here is how I solved the problem.
> > I decided to install WebPACK ISE 3.3 (Now it is called ISE WebPACK, but
> > I guess it doesn't matter.) which also comes with XST to my computer
> > where I already got ISE WebPACK 4.2.
> > I read some time ago that XST with WebPACK ISE 3.3 generates an EDIF
> > file instead of an encrypted .NGC file (The XST since ISE 4.1 does so,
> > unfortunately.), so I will manually edit the netlist to duplicate FFs.
> > The result is, when I tested it, NGDBUILD correctly read my PCI IP core
> > in a netlist, and MAP correctly pushed FFs I duplicated by hand into
> > IOBs.
> > The only problem is, it takes about 2 to 3 hours to duplicate all 95 or
> > so FFs by hand, using a text editor, but that's much better than not
> > being able to edit an encrypted netlist (.NGC file) at all.
> >
>
> I really and truely don't understand the decision to change from an
> ``industry standard'' format - i.e. EDIF - to a binary [and encrypted ?] one
> esp. as all the 3rd party tools output EDIF so NGDBUILD is always going to
> have to be able to handle it.
>
> The only thing I can come up with is the possibility that someone somewhere
> might write a ``technology retargeting'' tool and thus gain a free
> synthesiser for their architecture. However the EDIF file has a lot of
> technology optimisations specific to Xilinx [and even to a particular Xilinx
> device *family* ] built in so I'd say the QOR from this process wouldn't
> show the other technology in a very good light unless it was architecturally
> very close to Xilinx's ... at which point synth tools would be irrelevant as
> the case would already be in the hands of the patent lawyers.
>
> Anyone from Xilinx prepared to confirm that this is the reason ?
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 43320Phil Hays wrote: > <snip> > I'm not looking for certainty, I'm looking for better odds. The > probability of failure can be lowered by getting a more complete test, > which probably does not make economic sense for the majority of users. Sounds like a candidate for hard drive style 'bad sector' mapping (future), and also for some ability to 'seed' the P&R tools to deliberately use other resource : that way, if you suspect a HW node issue, roll the dice again, and re-check. Easier than replace of FPGA, or even multiple PCBs, esp at prototype stages. Of course, 99.9% of the time, it will be 'cockpit error'... -jgArticle: 43321
>While I don't know if this the case here, a good reason for an encrypted netlist >is to protect IP. The open format of the EDIF netlist with no means of >encrypting it is a major hindrance to those wishing to sell IP. But that gets you into the key distribution business which might be OK for IP, but sounds ugly for normal use. Security-by-obscurity is known not to work. It will just encourage the bad guys and annoy the good guys. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 43322
In article <3CE66E6E.16FD92D8@andraka.com>, Ray Andraka <ray@andraka.com> wrote: >OK, I didn't realize you were using 1 bit models. When I dabbled with >neural nets a few years ago, the synapses carried a number to represent >analog behavior, hence there was arithmetic and logic to implement the >linear and non-linear behavior. In any event, your neuron still needs some >logical function, perhaps a sum and binary threshold. I was referring to >the model of the neuron. Mine used a fixed connection network with the >strengths of the connections determined by the learning, where you >apparently want to actually make or break the connections. You might look >at block memories as the connection matrix. Thanks for the reply. All signals in my network are 1-bit discrete signals. I use several types of neurons and synapses. The neurons I use are spiking neurons: the arrival times of input signals are what decides whether or not a neuron fires, at least in most neurons. My synapses also have a connection strength that can be represented by an integer. The strength of some synapses is decremented by 1 every time they fire. In other neurons it is incremented. If the target neurons fires, synapses that contributed to the firing are strongly strengthened. The others are strongly weakened. Each neuron type has its own firing function that depends on the arrival times of input signals. Some neurons are coincidence detectors while others are sequence detectors. I am reasonably sure all these things can be accomplished using FPGA technology. What I am not sure about is whether one can use an FPGA-based network that has the ability to make an indefinite number of input and output connections between some neurons, (say, up to 200 connections). Can you elaborate a little on your suggestion to use block memories as the connection matrix? Temporal Intelligence: http://home1.gte.net/res02khr/AI/Temporal_Intelligence.htmArticle: 43323
Ray Andraka wrote:
>
> While I don't know if this the case here, a good reason for an encrypted netlist
> is to protect IP. The open format of the EDIF netlist with no means of
> encrypting it is a major hindrance to those wishing to sell IP.
>
Because it is so easy to convert an EDIF netlist to an encrypted
.NGO file in Xilinx's software, I have been thinking of licensing
(selling) my PCI IP core as an encrypted netlist when it is done.
However, does anyone know how I can do something similar in Altera's
tools?
LeonardoSpectrum-Altera generates an EDIF file, which is fine, but it
will be nice if I can somehow encrypt it.
Speaking of protecting IP cores, even a .NGO file is probably
not terribly safe considering that someone who doesn't want to pay for
it can easily get a copy from someone else.
I suppose the only value of a .NGO file is to prevent an FPGA-to-ASIC
conversion by companies like Lightspeed Semiconductor or AMI
Semiconductor.
However, in Altera's IP core program, I believe the user has to buy
(license) a key to program their devices, so just getting a copy of an
encrypted netlist from someone will probably not do any good.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 43324The Xilinx mapper reports total component usage (slices, BRAMs, DCMs, etc.), but how do I get a breakdown on a per-module basis? -Kevin
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