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
BAM wrote: > do u think that i am very late to persue a careeer in Digital design, > i mean which company would recruit a 28 year old guy with no previous > exp... Age is irrelevant. What matters is your interest level and projects that you have done. You may have to do some on your own to get started and demonstate your abilities. > i need an advice, since i think this field is somewhat special To start with, you need to learn an HDL and a simulator. -- Mike TreselerArticle: 41451
In the case where just the innards of the CLBs are getting reconfigured, I find
it is a whole lot easier just to use SRL16's and do a 'poor-mans' reconfiguration
by shifting new data into the SRL16. There are several benefits, all tool
related:
1) The pins to the SRL16 are not permuted like they are for a LUT, so there is no
having to figure out what the LUT pin assignments are
2) You can simulate the entire design with existing tools, including the
reconfiguration
3) The SRL16 reload can be faster: 16 clocks of your system clock to reload vs
many CCLK clocks to clock in a new frame
4) The SRL16's are supported by mainstream tools flow vs. a hacking approach
using jbits
5) no need to mess with the select map interface and potentially reconfiguring
wrong.
Some day, the tools might be there for partial reconfig, but right now, it is not
for the faint of heart nor for those who for whatever reason MUST use the
mainstream tools.
Peter Alfke wrote:
> Tim wrote:
>
> > Can you give us any insight into a realistic scenario for
> > tool support over the next few years? Or is it there already
> > if we just knew where to look?
>
> Tool support for partial reconfiguration was the question.
>
> I do not have a ready answer. Will try to research this.
> I have looked (very seriously) at designs where the course inter-CLB routing
> structure is constant, but the innards of the CLBs and DCMs are being
> re-configured. That is not too difficult.
> I will get involved more in J-Bits, maybe that is the (partial) answer...
> Peter Alfke
--
--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: 41452
Modular design and partial reconfiguration are two very different things. Modular
design is a capability in the software that should let you do place and route on
sections of a design separately, while partial reconfig lets you load pieces of the
design without (re)programming the whole enchilada. While the bitstreams between
spartanII and virtex (not virtexE) are identical, the silicon is not. SpartanII
and Virtex 2.5v have the same device features from a bitstream standpoint, thus the
ability for identical bitstreams. Nevertheless there are a few differences between
the spartanII and the 2.5v Virtex: One of those differences is that the spartanII
does not support the select map programming mode, which is the mechanism needed for
partial reconfiguration, ergo no partial reconfig in the spartanII devices.
rickman wrote:
> I am confused. I thought the web site clearly says that partial
> reconfiguration is currently supported in the tools for the VirtexE and
> VirtexII devices? Of course, this is clearly a marketing page with
> little technical detail, but they do make this claim without caveats.
>
> http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=partial_reconfig
>
> and
>
> http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=modular_design
>
> Am I reading something into this that is not there?
>
> It is also not clear to me if (or moreso why-not?) this is available for
> the Spartan-IIE chips. They are supposed to be the same as the VirtexE
> and I have heard they even support the same bit streams, even though
> they don't have as much BRAM. The modular design page says SpartanII is
> supported, but the Partial Reconfig page does not.
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design URL http://www.arius.com
> 4 King Ave 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX
--
--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: 41453I obviously have to do more homework here... Peter Alfke rickman wrote: > Peter Alfke wrote: > > > > Tim wrote: > > > > > Can you give us any insight into a realistic scenario for > > > tool support over the next few years? Or is it there already > > > if we just knew where to look? > > > > Tool support for partial reconfiguration was the question. > > > > I do not have a ready answer. Will try to research this. > > I have looked (very seriously) at designs where the course inter-CLB routing > > structure is constant, but the innards of the CLBs and DCMs are being > > re-configured. That is not too difficult. > > I will get involved more in J-Bits, maybe that is the (partial) answer... > > Peter Alfke > > I am confused. I thought the web site clearly says that partial > reconfiguration is currently supported in the tools for the VirtexE and > VirtexII devices? Of course, this is clearly a marketing page with > little technical detail, but they do make this claim without caveats. > > http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=partial_reconfig > > and > > http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=modular_design > > Am I reading something into this that is not there? > > It is also not clear to me if (or moreso why-not?) this is available for > the Spartan-IIE chips. They are supposed to be the same as the VirtexE > and I have heard they even support the same bit streams, even though > they don't have as much BRAM. The modular design page says SpartanII is > supported, but the Partial Reconfig page does not. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 41454
Ray you can partially reconfigure the Spartan II. The Spartan II has no master parallel mode. All the virtex (as far as I know) support partial reconfiguration. From xapp 176 Spartan-II FPGAs have the ability to be only partially re-configure or readback; however, this topic is beyond the scope of this note. For more information on partial configuration, Steve >One of those differences is that the spartanII > does not support the select map programming mode, which is the mechanism needed for > partial reconfiguration, ergo no partial reconfig in the spartanII devices.Article: 41455
Ray, I wrote "innards of the CLB" for a reason. I am not changing the LUTs, but rather the intra-CLB routing structure. For changing LUTs, your suggestion of using SRL16 is 100% right. Peter Alfke Ray Andraka wrote: > In the case where just the innards of the CLBs are getting reconfigured, I find > it is a whole lot easier just to use SRL16's and do a 'poor-mans' reconfiguration > by shifting new data into the SRL16. There are several benefits, all tool > related: > > 1) The pins to the SRL16 are not permuted like they are for a LUT, so there is no > having to figure out what the LUT pin assignments are > 2) You can simulate the entire design with existing tools, including the > reconfiguration > 3) The SRL16 reload can be faster: 16 clocks of your system clock to reload vs > many CCLK clocks to clock in a new frame > 4) The SRL16's are supported by mainstream tools flow vs. a hacking approach > using jbits > 5) no need to mess with the select map interface and potentially reconfiguring > wrong. > > Some day, the tools might be there for partial reconfig, but right now, it is not > for the faint of heart nor for those who for whatever reason MUST use the > mainstream tools. > > Peter Alfke wrote: > > > Tim wrote: > > > > > Can you give us any insight into a realistic scenario for > > > tool support over the next few years? Or is it there already > > > if we just knew where to look? > > > > Tool support for partial reconfiguration was the question. > > > > I do not have a ready answer. Will try to research this. > > I have looked (very seriously) at designs where the course inter-CLB routing > > structure is constant, but the innards of the CLBs and DCMs are being > > re-configured. That is not too difficult. > > I will get involved more in J-Bits, maybe that is the (partial) answer... > > Peter Alfke > > -- > --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, 1759Article: 41456
Yes, Partial Reconfiguration is not the same thing as Modular Design, but the first web page I referenced says that Modular Design is required to implement Partial Reconfiguration. The Modular Design web page includes Spartan-II&E while the Partial Reconfiguration web page only lists the Virtex & Virtex-II families. The SpartanII data sheet does not describe the Selectmap mode of configuraion, but it does describe Slave Parallel Mode which seems to be the same thing. The SpartanIIE data sheet uses both names together. So I doubt that the modes are different between the two chips. Ray Andraka wrote: > > Modular design and partial reconfiguration are two very different things. Modular > design is a capability in the software that should let you do place and route on > sections of a design separately, while partial reconfig lets you load pieces of the > design without (re)programming the whole enchilada. While the bitstreams between > spartanII and virtex (not virtexE) are identical, the silicon is not. SpartanII > and Virtex 2.5v have the same device features from a bitstream standpoint, thus the > ability for identical bitstreams. Nevertheless there are a few differences between > the spartanII and the 2.5v Virtex: One of those differences is that the spartanII > does not support the select map programming mode, which is the mechanism needed for > partial reconfiguration, ergo no partial reconfig in the spartanII devices. > > rickman wrote: > > > I am confused. I thought the web site clearly says that partial > > reconfiguration is currently supported in the tools for the VirtexE and > > VirtexII devices? Of course, this is clearly a marketing page with > > little technical detail, but they do make this claim without caveats. > > > > http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=partial_reconfig > > > > and > > > > http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=modular_design > > > > Am I reading something into this that is not there? > > > > It is also not clear to me if (or moreso why-not?) this is available for > > the Spartan-IIE chips. They are supposed to be the same as the VirtexE > > and I have heard they even support the same bit streams, even though > > they don't have as much BRAM. The modular design page says SpartanII is > > supported, but the Partial Reconfig page does not. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 41457
That page says partial reconfiguration can be "Enabled through the Modular Design software option," I'm sure you can "Enable" partial reconfiguration just by setting the persist option to yes. Of course the 3.xi software had no way to set this in the GUI so maybe that is what they are talking about. Steve "rickman" <spamgoeshere4@yahoo.com> wrote in message news:3CA3A641.55E9CA1E@yahoo.com... > Yes, Partial Reconfiguration is not the same thing as Modular Design, > but the first web page I referenced says that Modular Design is required > to implement Partial Reconfiguration. The Modular Design web page > includes Spartan-II&E while the Partial Reconfiguration web page only > lists the Virtex & Virtex-II families.Article: 41458
Hmm,
I was under the impression that partial reconfig was not supported by
SpartanII. The flurry of handbooks and documents is starting to make the tax
code look like a child's bedtime story. Peter, perhaps you can answer this
definitively: Is partial configuration supported in the SpartanII line, or is
that one of the features that got dropped out in the cost reducing die
shrink? Inquiring minds want to know!
Steve Casselman wrote:
> Ray you can partially reconfigure the Spartan II. The Spartan II has no
> master parallel mode. All the virtex (as far as I know) support partial
> reconfiguration.
>
> From xapp 176
>
> Spartan-II FPGAs have the ability to be only partially re-configure or
> readback; however, this
> topic is beyond the scope of this note. For more information on partial
> configuration,
>
> Steve
>
> >One of those differences is that the spartanII
> > does not support the select map programming mode, which is the mechanism
> needed for
> > partial reconfiguration, ergo no partial reconfig in the spartanII
> devices.
--
--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: 41459
Hi,
in a fpga design for our research project we have differencies
between functional simulation and timing simulation.
Our verilog design :
- use ActiveHDL in the foreground
- use a lot of VirtexE block RAM, logical simulation is ok.
- infer RAM like that:
/********************************************************************************
This module is a Dual Port Synchronous RAM.
The Xilinx sythesiser XST infers actual RAM from it.
Do not change it, but instatiate it in higher level modules.
*/
`timescale 1ns / 1ns
module DP_Syn_RAM
( clk, we, wr_addr, rd_addr, din, dout );
parameter
RAM_ADDR_WIDTH = 8,
DATA_WIDTH = 8,
RAM_DEPTH = 256;
input clk;
input we;
input [RAM_ADDR_WIDTH - 1:0] wr_addr;
input [RAM_ADDR_WIDTH - 1:0] rd_addr;
input [DATA_WIDTH - 1:0] din;
output [DATA_WIDTH - 1:0] dout;
reg [DATA_WIDTH - 1:0] ram [RAM_DEPTH - 1:0];
reg [RAM_ADDR_WIDTH - 1:0] read_addrb;
always @(posedge clk) begin
if (we)
ram[wr_addr] <= din;
read_addrb <= rd_addr;
end
assign dout = ram[read_addrb];
endmodule
//******************************************************************************
- higher level modules are fully synchronous [always @(posedge clk)...]
,
make sure that rd_addr is different from wr_addr at any time; but the
signal
interfacing the RAM are NOT latched as the VirtexE data sheet states:
"All inputs are registered with the port clock and have a
set-up to clock timing specification."
- asyncronous report is fine (max delay path ~9ns, while Tck=25ns)
- syntesis and implementation with XST
- from timing simulation we get a lot of errors like:
# : C:\Program Files\Aldec\Active-HDL
5.1\vlib\OVI_Simprim/./src/x_ramb4_s16_s16.v, 0:
Timing violation in
/daqpath/\ram_derandomizer/drnd13/Mram_ram_inst_ramb_7 \
# : $recovery(CLKB:13987,CLKA:13997,2328)
They happen at every clk edge, for most of the block rams.
- Some output waveforms are wrong: the dout from a few rams are wrong
and data seem to come from a location different from the location
actually addressed. These RAMs are part of o group of 24 parallel RAMs
(that is sharing the same address lines). Is a fanout problem ?
Thanks in advance for any help,
Tullio Grassi
======================================
Univ. of Maryland - Dept. of Physics
College Park, MD 20742 - US
Tel +1 301 405 5970
Fax +1 301 699 9195
======================================
Article: 41460
Change:
>assign dout = ram[read_addrb];
To:
dout <= ram(read_addrb);
On Thu, 28 Mar 2002 19:27:41 -0500, Tullio Grassi
<tullio@physics.umd.edu> wrote:
>Hi,
>
> in a fpga design for our research project we have differencies
>between functional simulation and timing simulation.
>Our verilog design :
>- use ActiveHDL in the foreground
>- use a lot of VirtexE block RAM, logical simulation is ok.
>- infer RAM like that:
>
> /********************************************************************************
>
>This module is a Dual Port Synchronous RAM.
>The Xilinx sythesiser XST infers actual RAM from it.
>Do not change it, but instatiate it in higher level modules.
>*/
>`timescale 1ns / 1ns
>module DP_Syn_RAM
> ( clk, we, wr_addr, rd_addr, din, dout );
>parameter
> RAM_ADDR_WIDTH = 8,
> DATA_WIDTH = 8,
> RAM_DEPTH = 256;
>
> input clk;
> input we;
> input [RAM_ADDR_WIDTH - 1:0] wr_addr;
> input [RAM_ADDR_WIDTH - 1:0] rd_addr;
> input [DATA_WIDTH - 1:0] din;
> output [DATA_WIDTH - 1:0] dout;
>
> reg [DATA_WIDTH - 1:0] ram [RAM_DEPTH - 1:0];
> reg [RAM_ADDR_WIDTH - 1:0] read_addrb;
>
>always @(posedge clk) begin
> if (we)
> ram[wr_addr] <= din;
> read_addrb <= rd_addr;
> end
>assign dout = ram[read_addrb];
>endmodule
>//******************************************************************************
>
>- higher level modules are fully synchronous [always @(posedge clk)...]
>,
> make sure that rd_addr is different from wr_addr at any time; but the
>signal
> interfacing the RAM are NOT latched as the VirtexE data sheet states:
> "All inputs are registered with the port clock and have a
> set-up to clock timing specification."
>- asyncronous report is fine (max delay path ~9ns, while Tck=25ns)
>- syntesis and implementation with XST
>- from timing simulation we get a lot of errors like:
> # : C:\Program Files\Aldec\Active-HDL
>5.1\vlib\OVI_Simprim/./src/x_ramb4_s16_s16.v, 0:
> Timing violation in
>/daqpath/\ram_derandomizer/drnd13/Mram_ram_inst_ramb_7 \
> # : $recovery(CLKB:13987,CLKA:13997,2328)
> They happen at every clk edge, for most of the block rams.
>- Some output waveforms are wrong: the dout from a few rams are wrong
> and data seem to come from a location different from the location
> actually addressed. These RAMs are part of o group of 24 parallel RAMs
>
> (that is sharing the same address lines). Is a fanout problem ?
>
>Thanks in advance for any help,
>
>Tullio Grassi
>
>======================================
>Univ. of Maryland - Dept. of Physics
>College Park, MD 20742 - US
>Tel +1 301 405 5970
>Fax +1 301 699 9195
>======================================
>
Article: 41461I have built an Altera downloading-cable based on the ByteBlasterMV datasheet. The problem is that it won't work. So where do I start troubleshooting? I've checked all connections, so that shouldn't be the problem. And is the cable supposed to be able to detect without being connected to the target board (only power-supply)? Please help me out, I'm a very poor student and I can't afford to spend $150 (or more likely twice of that over here in Sweden).Article: 41462
Changchun Core version 0.0 is not valid means that you have not inserted a ILA core using the ILA core inserter or by instaniating one in VHDL. When you install MULTILINX it will install the appropriate driver. I am using WIN 2000 and it works fine except for the ocassional "Internal Error: Failed to execute api function." Ignore this error. Bill "Changchun WAN" <ccwan@phys.sinica.edu.tw> wrote in message news:a7dgrg$2suo$1@news1.sinica.edu.tw... > Hi > > When I opened the serial MultiLINX port in chipscope I got an error message > "Internal Error: Failed to execute api function." > > Then it initialized the the port and reported success. I can setup the > boundary scan chain and got correct device information, but when I > downloaded the .bit to the device another error message appeared: > > "Core version 0.0 is not valid or not supported. Please verify that all > instruction register lengths in the JTAG chain are properly specified." > > But in fact the instruction register length is right and got by JTAG chain > automatically. (only XILINX device in the chain) > > The device can work after download, but I can not setup trig signal etc. The > error message is also "Core version 0.0 is ... " > > Who can give me some suggestion? Thanks! > > By the way, my MultiLINX had never worked successfully with USB cable. Does > Win2000 need install some driver? > > Changchun > >Article: 41463
>> Hi All,
>>
>> I have encountered a strange problem on a board we have designed. The
>> board contains a Xilinx Spartan II XC2S200, two Xilinx XC95288XL CPLDs,
>> and one Xilinx XC95144XL CPLD.
>>
>> There are three power supply voltages on the board: 2.5V for the Spartan
>> II core, 3.3V for the CPLDs and the Spartan II I/O, and 5V for some RAM
>> and ROM.
>>
>> There is a 19.6608MHz Crystal Oscillator Module running on the 5V rail,
>> which provides a clock to the four Xilinx chips. This clock rings more
>> than I would like, so I wish to terminate it using pads included in the
>> design for this reason.
So if I understand this correctly, you're clocking chips on 2.5V and 3.3V supplies from an oscillator that runs on 5V and
therefor produces a signal of 5Vpp. What might happen here is that when the oscillator pulse is high (+5V), it lifts the clock
input of the chips on 2.5V and 3.3V above their rails. The protection diodes on those inputs will go in forward and dump the
excess pulse power in the VDD rail on the chip! Worst case this triggers a latch up but you only seem to suffer from
interference ("unreliability").
>> Using information from the manufacturer I have established that the
>> impedance of the clock trace is around 90 Ohms, so I terminated it to 5V
>> and to ground, each with 180 Ohm resistors.
What happens now is that the clock has a more difficult time to swing rail-to-rail. Maybe it now only swings 1V to 4V instead of
the usual 'almost' 0V to 5V.
>> When I do this, however, the JTAG test access port on the Spartan II
>> appears to become unreliable - I am not able to configure the Spartan II
>> via JTAG.
Maybe you get in trouble with the low level requirement. Suppose you've squeezed the clock so much that it swings 1.5V to 3.5V.
I expect the input trigger of the chip on 2.5V to be at 1.25V and the clock doesn't reach down to 1.25V anymore.
In case of ringing you might get 'double clocks' when the low level approaches the trigger.
>> I tried terminating just to Ground (ie. removing the resistor from the
>> clock net to 5V). This seemed to make things better, but did not fix the
>> problem completely.
Now the clock has trouble reaching up to 5V but down to 0V is no problem. This supports the theory that you're feeding the poor
chips at 2.5V and 3.3V with a much to large clock signal.
What you could try is a resistor divider to reduce the clock pulse down to levels that stay within the supply of the receiving
chips.
To reduce 5V down to 3.3V, you could use 50 Ohm in series with the output and then 100 Ohm to ground.
To reduce 5V down to 2.5V, you could use 75 Ohm in series with the output and another 75 Ohm to ground.
Hope this helps.
Best regards,
Eddy van Keulen
Fremont California
Article: 41464
Okay, here is a continuation of "Unrecognized LUTs Inserted in A
FLEX10KE/ACEX1K Design" posting I made.
I just did another P&R in Quartus II 2.0 Web Edition targeting
FLEX10K100E-1, and got very strange results for one of the pin's Tco.
The pin in question is Pin W9, and PCI's FRAME# signal is connected to
this pin.
1: + IC(0.000 ns) + CELL(0.000 ns) = 0.000 ns; Loc. = LC1_L18; REG Node
= 'FRAME_n_OE_n~reg0'
2: + IC(6.700 ns) + CELL(3.500 ns) = 10.200 ns; Loc. = Pin_W9; PIN Node
= 'FRAME_n'
1: + IC(0.000 ns) + CELL(0.000 ns) = 0.000 ns; Loc. = LC8_L18; REG Node
= 'FRAME_n_Port~reg0'
2: + IC(0.200 ns) + CELL(4.900 ns) = 5.100 ns; Loc. = Pin_W9; PIN Node =
'FRAME_n'
This FRAME_n pin is a bidirectional pin, so there is a tri-state
buffer before the pin.
Both FRAME_n_OE_n~reg0 (An Output Enable FF) and FRAME_n_Port~reg0 (An
output FF) are located in LAB L18 which is located right above pin W9.
Even though they are from the same LAB, the routing delay for
FRAME_n_Port~reg0 is 0.2ns, which is very good, but for some reason
FRAME_n_OE_n~reg0's routing delay is staggering 6.700 ns, which I don't
understand why can it be that bad considering the physical location of
the FF.
Did FLEX10KE somehow ran out of routing channels, and the routing for
FRAME_n_OE_n~reg0 got diverted?
Or is the automatic P&R tool that bad in QII?
I didn't use an IOE FF for FRAME_n_Port~reg0 because of FLEX10KE's IOE
doesn't seem to support asynchronous preset.
For synthesis, I used QII's native Verilog synthesis (Altera in-house
synthesis tool) instead of LeonardoSpectrum-Altera because I didn't feel
like using LS-Altera for this experiment. (I will try to use it later.)
Thanks,
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 41465
Peter Alfke wrote:
>
>
> We have looked at this several times. Here is my -somewhat personal- opinion:
>
> The standard CMOS process without any exotic additions ( like EEPROM or
> antifuse) is always better ( smaller, faster, higher-yielding, and earlier
> available) than a mixed process. We prefer the most aggressive
> microprocessor-oriented process.
>
Although, I don't know much about it, but it seemed like
anti-fuse FPGAs used to be more competitive in the '90s compared to
SRAM-based FPGAs, but now they seem to have gotten quite behind in terms
of performance or density.
Were the anti-fuse camp more competitive in terms of process technology
in the early to mid '90s?
Will MRAM or some other non-volatile storage technology replace
SRAM at some point because of soft error concern at some process
technology? (I do realize that MRAM is nowhere near being a high volume
commercial product like flash.)
> The benefit of a EEPROM-based FPGA are really limited to very small designs,
> (where single-chip is seen as an advantage) and to certain high-security
> applications, which we already cover with triple-DES encrypted bitstreams.
>
> The market niche is small, and we prefer our present, very successful approach.
>
> Peter Alfke
Then how come CPLDs remain almost all EEPROM?
Also, why doesn't CPLD's density almost never seem to go above 512 or
1,024 macrocells? (Except Cypress' Delta 39K which is SRAM-based.)
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 41466Alexander Miks wrote: > > I have built an Altera downloading-cable based on the ByteBlasterMV > datasheet. The problem is that it won't work. So where do I start > troubleshooting? I've checked all connections, so that shouldn't be the > problem. And is the cable supposed to be able to detect without being > connected to the target board (only power-supply)? > Please help me out, I'm a very poor student and I can't afford to spend $150 > (or more likely twice of that over here in Sweden). Have you got a 100nF cap across the 74HC244?Article: 41467
Do you aware of any Virtex II pro development board on market? and Which high density FPGA board you would suggest? Thanks, ~pat!Article: 41468
Power your home-build ByteBlaster using 5V or 3V3 power supply (not connected to computer or FPGA). Then feed to inputs (both computer side and FPGA side) GND and VCC and check with multimeter that the other side of 74HC244 responds properly. If possible, test also with genuine ByteBlasterMV that settings of your software are correct and test that you don't have a dead FPGA (they are static sensitive devices. Have separate ground wire connected between computer and FPGA-ground when using ByteBlaster). -- Tuomo AuerArticle: 41469
There is a 32bit data in a register.how do i know the bit "1"'s position? for example: 01010000110011001101010001100010 the bit "1"'s position is : 1/5/6/10/12/14/15/18/19/22/23/28/30. how do implemention it with verilog code?Article: 41470
hi thanks all,
you are right ken.
I just read the manual and find out that the wild card "*" does not
match ".", so I still have to give the corrected no of "."
thanks
pyng
Ken McElvain <ken@synplicity.com> wrote in message news:<3CA34C5B.4090207@synplicity.com>...
> You need
>
> define_attribute {<entityname>|I_1*} syn_multstyle {logic}
>
> The syntax {<entityname>|<objectname>} finds object <objectname>
> relative to <entityname>. <entityname> is not a path, it is
> simply the VHDL entityname or verilog module name.
>
> I imagine that you have multiple instantiations of the entity/module
> containing the multipler.
>
>
> spyng wrote:
>
> > hi,
> > I have try syn_multstyle both in the verilog code and in the sdc
> > constraint file.
> >
> > although, in the *.srr log file it did show that property is added,
> > but both in the gate level netlist *.srm and the edf the mult18*18 is
> > still there. any one know is there a bug with the syn_multstyle?
> >
> > in the *.sdc
> > define_attribute {*mult_26bitx4bit_3.I_1*} syn_multstyle
> > {logic}
> >
> > in the *.srr
> > Adding property syn_multstyle, value "logic", to instance
> > mult_26bitx4bit_3.I_1
> >
> > in the *.edf
> > (instance (rename mult_26bitx4bit_3_I_1 "mult_26bitx4bit_3.I_1")
> > (viewRef PRIM (cellRef MULT18X18 (libraryRef VIRTEX)))
> >
> > any help?
> > spyng
> > thanks
> >
> >
> >
> >
> >
> >
> > sunny <sunshine@sunrise.at> wrote in message news:<ee75cf4.0@WebX.sUN8CHnE>...
> >
> >>u could use the synplify attribute
> >>syn_multstyle = logic. This would prevent Synplify of using the 18x18 multiplier. Information will be forward annotated to ISE thru the ncf.
> >>
Article: 41471Thanks for the answear, I found out that the error was a glitch in the DSUB and a broken pin on the PLCC socket (bad luck that this pin was one of the JTAG-pins). But I think I fried my EPM7064S when testing. I hooked it up as a simple T-flip-flop, with one input and one output. The output connected to a LED (through a resistor), and the input to a cable floating in the air (I know that's NOT the way to go...). I then powered it up and toggled the input-cable between ground and vcc. Wow, it worked... But I almost got a chock when touching the chip, it was smoking hot! After that the chip "works" but programmer gets no contact... Do you need a current-limiting resistor on the input or what did I do wrong? "Tuomo Auer" <tuomo.auer@removethis.hut.fi> skrev i meddelandet news:a81k8m$pnr$1@tron.sci.fi... > Power your home-build ByteBlaster using 5V or 3V3 power supply (not > connected to computer or FPGA). Then feed to inputs (both computer side and > FPGA side) GND and VCC and check with multimeter that the other side of > 74HC244 responds properly. > > If possible, test also with genuine ByteBlasterMV that settings of your > software are correct and test that you don't have a dead FPGA (they are > static sensitive devices. Have separate ground wire connected between > computer and FPGA-ground when using ByteBlaster). > > -- > Tuomo Auer > >Article: 41472
Where can I get the MAX7000S-series of chips in Sweden. Do you know of any place shipping devices over here. I know a place here in Sweden, but they only have the 7064S.Article: 41473
Check unused pins. As a default these pins are configures as outputs, so they must not be connected to GND or VCC but must be left open. You can check yhis out from the report file. Dedicated inputs instead mus be connected to known logic state (not to be left floating). -- Tuomo AuerArticle: 41474
Hi,
Also check that the computer's parallel port is okay! It could be
misconfigured, try the cable on a different computer. Also I think
that the cable is dumb. It doesn't have a micrcontroller on it, so the
software has no way of checking if the cable is working without being
connected to the target.
-Colin
"Tuomo Auer" <tuomo.auer@removethis.hut.fi> wrote in message news:<a81k8m$pnr$1@tron.sci.fi>...
> Power your home-build ByteBlaster using 5V or 3V3 power supply (not
> connected to computer or FPGA). Then feed to inputs (both computer side and
> FPGA side) GND and VCC and check with multimeter that the other side of
> 74HC244 responds properly.
>
> If possible, test also with genuine ByteBlasterMV that settings of your
> software are correct and test that you don't have a dead FPGA (they are
> static sensitive devices. Have separate ground wire connected between
> computer and FPGA-ground when using ByteBlaster).
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