Messages from 131175

Article: 131175
Subject: Re: Which to learn: Verilog vs. VHDL?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 14 Apr 2008 07:58:55 -0700
Links: << >> << T >> << A >>

Michael wrote:
> which would be more useful to learn in the industrial world: Verilog
> or VHDL?

Better learn both.
This has been well covered:
http://groups.google.com/groups/search?q=vhdl+vs+verilog

      -- Mike Treseler

Article: 131176
Subject: Actel Cortex
From: "John Aderseen" <john@aderseen.com>
Date: Mon, 14 Apr 2008 17:22:29 +0200
Links: << >> << T >> << A >>

Hey,

Does anybody know if there is a port of Linux on the ARM-Cortex on Actel ?

Thanks,
John

Article: 131177
Subject: Re: XST support for User Defined Primitives
From: mk <kal@deletethis.dspia.com>
Date: Mon, 14 Apr 2008 16:02:39 GMT
Links: << >> << T >> << A >>

On Sun, 13 Apr 2008 23:02:23 -0700 (PDT), Goli <togoli@gmail.com>
wrote:

>Hi,
>
>Does anyone know if user defined Primitives are supported with XST, I
>have the following code and it is giving error,

UDPs are not synthesizable. You're better off using a behavioral
definition for the 4-1 mux you have. If your code depends on the fact
that when all inputs are the same, the output becomes that value
regardles of the select input, you can model that too but you have
remember to suppress it for synthesis.

Article: 131178
Subject: DOS script file to synthesize a VHDL design
From: Sue <sudhangi@gmail.com>
Date: Mon, 14 Apr 2008 10:43:52 -0700 (PDT)
Links: << >> << T >> << A >>

Does anyone know how can I get started on making a DOS script file to
synthesize a VHDL design. I tried understanding something from:
http://toolbox.xilinx.com/docsan/xilinx5/pdf/docs/xst/xst.pdf

But I still need more help.
Can someone please tell me the sequence which I should follow.

Thanks

Article: 131179
Subject: "Multi-source in Unit" Verilog synthesis woes
From: NRClark <nicholas.clark@gmail.com>
Date: Mon, 14 Apr 2008 11:27:49 -0700 (PDT)
Links: << >> << T >> << A >>

Hi everybody,

I'm working on a hobbyist board I'm designing to do some audio DSP.
I'm a little new to Verilog,
although not to programming in general. So far the FPGA design work
has been going smoothly
enough, but I'm having some trouble with synthesizing the code I wrote
for my DAC. I tried to avoid
all of the 'common' mistakes and design for synthesizability, but
there's some I must have missed.

My design simulates just fine, but when I go to synthesize it I get
these weird "Multi-source" errors:

ERROR:Xst:528 - Multi-source in Unit <dac_cs4345> on signal
<shift_counter<4>>
ERROR:Xst:528 - Multi-source in Unit <dac_cs4345> on signal
<shift_counter<2>>
ERROR:Xst:528 - Multi-source in Unit <dac_cs4345> on signal
<shift_counter<1>>
ERROR:Xst:528 - Multi-source in Unit <dac_cs4345> on signal
<Msub__COND_2_Madd>
ERROR:Xst:528 - Multi-source in Unit <dac_cs4345> on signal
<Mcount_shift_counter>.

I can't find the bug in my design, which means it must be some bug in
my own understanding. :)

Any words of insight? My Verilog code follows.

Thanks,
Nick

//------------------------------------
code----------------------------------------
module dac_cs4345(CLK,		RST_N,	SCLK,
						LRCLK,	L_DATA,	R_DATA,
						DATAOUT);

//	In this design, CLK = 49.152MHz, MCLK = 24.576MHz,
//	SCLK = 6.144MHz, LRCLK = 96KHz. They are all in-phase
//	each other, with the various clocks being generated from
// a 49.152MHz crystal and another Veriog module containing
// counters.

// Module port declarations

	input CLK,	RST_N;
	input SCLK,	LRCLK;
	input [23:0] L_DATA, R_DATA;

	output reg DATAOUT;

// Internal declarations

	reg r1, r2;
	wire SCLK_DELAYED;

// Counter used as an index to access data serially.
	reg [4:0] shift_counter;

// L_Data and R_Data are both registered to protect against
// spurious transitions during conversion.
	reg [23:0] L_DATA_STORAGE;
	reg [23:0] R_DATA_STORAGE;

//	Begin Program

// Since our data is set up on the LRCLK edge, we have to allow
// some delay before accessing it. Since SCLK is the clock used
// pull data, a slightly delayed SCLK will be generated and used.
// SCLK_DELAYED arrives one CLK period after SCLK.

	always @(posedge CLK) begin
		r2 <= r1;
		r1 <= SCLK;
	end
	assign SCLK_DELAYED = r2;

// Both the L and R data are assumed to arrive at this module
// at the same time, and to be available at the rising
// edge of the provided LRCLK. Since LRCLK is the output
// waveform used for synching data, this is a valid assumption.
// L_data and R_data _must_ be set up some time before the
//	positive edge of LRCLK.

	always @(posedge LRCLK) begin
		L_DATA_STORAGE <= L_DATA;
		R_DATA_STORAGE <= R_DATA;
		shift_counter <= 31; // Reset count-down counter
	end

	always @(negedge LRCLK)
		shift_counter <= 31; // Reset count-down counter

// Output data is assigned here. DATAOUT is assigned the value of
// 0 if our counter has gone past the data's LSB. The DAC's
// left-channel data is supplied when LRCLK is high, and its
// right-channel data is spplied when LRCLK is low.

	always @(posedge SCLK_DELAYED) begin
		if(shift_counter < 8)
			DATAOUT = 0;
		else if(LRCLK == 1)
			DATAOUT = L_DATA_STORAGE[shift_counter-8];
		else
			DATAOUT = R_DATA_STORAGE[shift_counter-8];
	end

// The timing of this is such that shift_counter counts down
//	from 32 to 0 twice in each LRCLK - once per 'side'. This is
//	decremented after the output has already been assigned a value.
// shift_counter could also be decremented on the falling edge of
// SCLK_DELAYED without changing the result.

	always @(negedge SCLK) begin
		shift_counter <= shift_counter-1;
	end

	endmodule

Article: 131180
Subject: Re: case statements- verilog to vhdl
From: FP <FPGA.unknown@gmail.com>
Date: Mon, 14 Apr 2008 12:03:04 -0700 (PDT)
Links: << >> << T >> << A >>

On Apr 11, 5:18=A0pm, Andy <jonesa...@comcast.net> wrote:
> On Apr 11, 2:17 pm, Dave Pollum <vze24...@verizon.net> wrote:
>
>
>
>
>
> > On Apr 11, 1:08 pm, FP <FPGA.unkn...@gmail.com> wrote:
>
> > > I have the following scenario in verilog which i need to convert to
> > > vhdl
>
> > > always
> > > if reset
> > > .
> > > .
> > > .
> > > else
> > > =A0 case
> > > =A0 .
> > > =A0 .
> > > =A0 .
> > > =A0end case
> > > =A0// set default values
> > > =A0case.
> > > =A0.
> > > =A0.
> > > =A0.
> > > =A0.
> > > end case
> > > end
>
> > > How do I convert this to vhdl. I am lost on what the equivalent of =A0=
//
> > > set default values and the case statements after that would be in
> > > VHDL.
>
> > I'm not a Verilog person, but I do have a book that shows both VHDL
> > and Verilog code ("HDL Chip Design", by Douglas J. Smiths). =A0The book
> > shows that "//" is a Verilog comment. =A0So, "// set default values" is
> > a comment. =A0The Verilog "default" is the same as the VHDL "when others=

> > =3D>". =A0"always@ .. end" is the same as a VHDL "process .. end
> > process". =A0In your case (no pun intended), it's a combinatorial
> > process.
> > HTH
> > -Dave Pollum
>
> The presence of "if reset" could imply that this is a clocked process,
> not combinatorial. We can't tell because the "always" statement is not
> included, and we cannot tell if the block is also sensitive to posedge
> clock.
>
> Andy- Hide quoted text -
>
> - Show quoted text -

I have 2 case statement in 1 always loop in my verilog file. I am not
sure how this should be implemented in VHDL. I am aware of the syntax.
=46rom design point of view I am not sure if I should be putting them in
2 seperate process statements.

Verilog =3D>

always @ posedge clk
c1 : case(cmd) is
  when a =3D> bunch of statements
  when b =3D> bunch of statements
  when c =3D> bunch of statements
  when d =3D> bunch of statements
  default =3D> bunch of statements
end case c1

c2 : case(cmd) is
  when a =3D> bunch of statements
  when b =3D> bunch of statements
  when c =3D> bunch of statements
  when d =3D> bunch of statements
  default =3D> bunch of statements
end case c2

end

My question is
1) Is the VHDL equivalent of the above, 2 case statements in one
process or 2 different processes with 1 case each? The problem with 2
processes I am facing is access  of varaibles.
2) The above is similar to an FSM. One case statement is executing the
present command, while the other is completing the last command. Any
idea on how this should be converted to VHDL?

Article: 131181
Subject: Re: Actel Cortex
From: job@amontec.com
Date: Mon, 14 Apr 2008 12:12:07 -0700 (PDT)
Links: << >> << T >> << A >>

On Apr 14, 5:22 pm, "John Aderseen" <j...@aderseen.com> wrote:
> Hey,
>
> Does anybody know if there is a port of Linux on the ARM-Cortex on Actel ?
>
> Thanks,
> John

Is the Actel one Cortex-M3 or cortex-M8 ?

If M3, it should not have any MMU, also no possibility for you to get
a Linux (but you could get a uc-linux, or other smaller OS)
If M8, as the ARM11 serie, it should have a MMU, also it is possible
to port Linux on it.

Regards,
Laurent Gauch
 http://www.amontec.com
JTAG solutions from Download to Debug for ARM or FPGA.

Article: 131182
Subject: Re: case statements- verilog to vhdl
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 14 Apr 2008 13:01:10 -0700
Links: << >> << T >> << A >>

FP wrote:

> From design point of view I am not sure if I should be putting them in
> 2 seperate process statements.

No. One verilog block is one vhdl process.

> My question is
> 1) Is the VHDL equivalent of the above, 2 case statements in one
> process or 2 different processes with 1 case each?

one process

> 2) The above is similar to an FSM. One case statement is executing the
> present command, while the other is completing the last command. Any
> idea on how this should be converted to VHDL?

Did the verilog version work?

         -- Mike Treseler

Article: 131183
Subject: Re: Intel plans to tackle cosmic ray threat (actually they have been
From: cs_posting@hotmail.com
Date: Mon, 14 Apr 2008 13:19:20 -0700 (PDT)
Links: << >> << T >> << A >>

On Apr 8, 4:27 pm, austin <aus...@xilinx.com> wrote:

> The direction is predominately "up" as the flux falls off away from "up"
> (towards the sky) as the neutrons are absorbed by the atmosphere at
> oblique angles.

That would seem to suggest the semiconductor dies should always be
oriented in the vertical plane -
substantial reduction in cross sectional exposure, plus anything that
does hit it might affect a longer
"scratch" of circuitry rather than just a point?   Assuming I guess
that the interaction isn't entirely confined to discrete points along
the flight path by quantum effects.

Article: 131184
Subject: Re: "Multi-source in Unit" Verilog synthesis woes
From: "Alvin Andries" <Alvin_Andries.no_spam@no.spam.versateladsl.be>
Date: Mon, 14 Apr 2008 22:55:08 +0200
Links: << >> << T >> << A >>


"NRClark" <nicholas.clark@gmail.com> wrote in message
news:5b377f74-9395-46de-b771-dccba3d994d1@k1g2000prb.googlegroups.com...
> Hi everybody,
>
> I'm working on a hobbyist board I'm designing to do some audio DSP.
> I'm a little new to Verilog,
> although not to programming in general. So far the FPGA design work
> has been going smoothly
> enough, but I'm having some trouble with synthesizing the code I wrote
> for my DAC. I tried to avoid
> all of the 'common' mistakes and design for synthesizability, but
> there's some I must have missed.
>
> My design simulates just fine, but when I go to synthesize it I get
> these weird "Multi-source" errors:
>
> ERROR:Xst:528 - Multi-source in Unit <dac_cs4345> on signal
> <shift_counter<4>>
> ERROR:Xst:528 - Multi-source in Unit <dac_cs4345> on signal
> <shift_counter<2>>
> ERROR:Xst:528 - Multi-source in Unit <dac_cs4345> on signal
> <shift_counter<1>>
> ERROR:Xst:528 - Multi-source in Unit <dac_cs4345> on signal
> <Msub__COND_2_Madd>
> ERROR:Xst:528 - Multi-source in Unit <dac_cs4345> on signal
> <Mcount_shift_counter>.
>
> I can't find the bug in my design, which means it must be some bug in
> my own understanding. :)
>
> Any words of insight? My Verilog code follows.
>
> Thanks,
> Nick
>
> //------------------------------------
> code----------------------------------------
> module dac_cs4345(CLK, RST_N, SCLK,
> LRCLK, L_DATA, R_DATA,
> DATAOUT);
>
> // In this design, CLK = 49.152MHz, MCLK = 24.576MHz,
> // SCLK = 6.144MHz, LRCLK = 96KHz. They are all in-phase
> // each other, with the various clocks being generated from
> // a 49.152MHz crystal and another Veriog module containing
> // counters.
>
> // Module port declarations
>
> input CLK, RST_N;
> input SCLK, LRCLK;
> input [23:0] L_DATA, R_DATA;
>
> output reg DATAOUT;
>
> // Internal declarations
>
> reg r1, r2;
> wire SCLK_DELAYED;
>
> // Counter used as an index to access data serially.
> reg [4:0] shift_counter;
>
> // L_Data and R_Data are both registered to protect against
> // spurious transitions during conversion.
> reg [23:0] L_DATA_STORAGE;
> reg [23:0] R_DATA_STORAGE;
>
> // Begin Program
>
> // Since our data is set up on the LRCLK edge, we have to allow
> // some delay before accessing it. Since SCLK is the clock used
> // pull data, a slightly delayed SCLK will be generated and used.
> // SCLK_DELAYED arrives one CLK period after SCLK.
>
> always @(posedge CLK) begin
> r2 <= r1;
> r1 <= SCLK;
> end
> assign SCLK_DELAYED = r2;
>
> // Both the L and R data are assumed to arrive at this module
> // at the same time, and to be available at the rising
> // edge of the provided LRCLK. Since LRCLK is the output
> // waveform used for synching data, this is a valid assumption.
> // L_data and R_data _must_ be set up some time before the
> // positive edge of LRCLK.
>
> always @(posedge LRCLK) begin
> L_DATA_STORAGE <= L_DATA;
> R_DATA_STORAGE <= R_DATA;
> shift_counter <= 31; // Reset count-down counter
> end
>
> always @(negedge LRCLK)
> shift_counter <= 31; // Reset count-down counter
>
> // Output data is assigned here. DATAOUT is assigned the value of
> // 0 if our counter has gone past the data's LSB. The DAC's
> // left-channel data is supplied when LRCLK is high, and its
> // right-channel data is spplied when LRCLK is low.
>
> always @(posedge SCLK_DELAYED) begin
> if(shift_counter < 8)
> DATAOUT = 0;
> else if(LRCLK == 1)
> DATAOUT = L_DATA_STORAGE[shift_counter-8];
> else
> DATAOUT = R_DATA_STORAGE[shift_counter-8];
> end
>
> // The timing of this is such that shift_counter counts down
> // from 32 to 0 twice in each LRCLK - once per 'side'. This is
> // decremented after the output has already been assigned a value.
> // shift_counter could also be decremented on the falling edge of
> // SCLK_DELAYED without changing the result.
>
> always @(negedge SCLK) begin
> shift_counter <= shift_counter-1;
> end
>
> endmodule

You adjust shift_counter in multiple processes (always @), which won't do.
You should only have 1 clocked process modifying shift_counter.
With all clocks being synchronously divided versions of CLK = 49.152MHz, you
should substitute the other clocks by "enable"/edge detect signals clocked
on CLK. The low frequency clocks can still be made available/imported from
the external world.

Regards,
Alvin.

Article: 131185
Subject: Re: "Multi-source in Unit" Verilog synthesis woes
From: Gabor <gabor@alacron.com>
Date: Mon, 14 Apr 2008 14:30:31 -0700 (PDT)
Links: << >> << T >> << A >>

On Apr 14, 4:55 pm, "Alvin Andries"
<Alvin_Andries.no_s...@no.spam.versateladsl.be> wrote:
> "NRClark" <nicholas.cl...@gmail.com> wrote in message
>
> news:5b377f74-9395-46de-b771-dccba3d994d1@k1g2000prb.googlegroups.com...
>
>
>
> > Hi everybody,
>
> > I'm working on a hobbyist board I'm designing to do some audio DSP.
> > I'm a little new to Verilog,
> > although not to programming in general. So far the FPGA design work
> > has been going smoothly
> > enough, but I'm having some trouble with synthesizing the code I wrote
> > for my DAC. I tried to avoid
> > all of the 'common' mistakes and design for synthesizability, but
> > there's some I must have missed.
>
> > My design simulates just fine, but when I go to synthesize it I get
> > these weird "Multi-source" errors:
>
> > ERROR:Xst:528 - Multi-source in Unit <dac_cs4345> on signal
> > <shift_counter<4>>
> > ERROR:Xst:528 - Multi-source in Unit <dac_cs4345> on signal
> > <shift_counter<2>>
> > ERROR:Xst:528 - Multi-source in Unit <dac_cs4345> on signal
> > <shift_counter<1>>
> > ERROR:Xst:528 - Multi-source in Unit <dac_cs4345> on signal
> > <Msub__COND_2_Madd>
> > ERROR:Xst:528 - Multi-source in Unit <dac_cs4345> on signal
> > <Mcount_shift_counter>.
>
> > I can't find the bug in my design, which means it must be some bug in
> > my own understanding. :)
>
> > Any words of insight? My Verilog code follows.
>
> > Thanks,
> > Nick
>
> > //------------------------------------
> > code----------------------------------------
> > module dac_cs4345(CLK, RST_N, SCLK,
> > LRCLK, L_DATA, R_DATA,
> > DATAOUT);
>
> > // In this design, CLK = 49.152MHz, MCLK = 24.576MHz,
> > // SCLK = 6.144MHz, LRCLK = 96KHz. They are all in-phase
> > // each other, with the various clocks being generated from
> > // a 49.152MHz crystal and another Veriog module containing
> > // counters.
>
> > // Module port declarations
>
> > input CLK, RST_N;
> > input SCLK, LRCLK;
> > input [23:0] L_DATA, R_DATA;
>
> > output reg DATAOUT;
>
> > // Internal declarations
>
> > reg r1, r2;
> > wire SCLK_DELAYED;
>
> > // Counter used as an index to access data serially.
> > reg [4:0] shift_counter;
>
> > // L_Data and R_Data are both registered to protect against
> > // spurious transitions during conversion.
> > reg [23:0] L_DATA_STORAGE;
> > reg [23:0] R_DATA_STORAGE;
>
> > // Begin Program
>
> > // Since our data is set up on the LRCLK edge, we have to allow
> > // some delay before accessing it. Since SCLK is the clock used
> > // pull data, a slightly delayed SCLK will be generated and used.
> > // SCLK_DELAYED arrives one CLK period after SCLK.
>
> > always @(posedge CLK) begin
> > r2 <= r1;
> > r1 <= SCLK;
> > end
> > assign SCLK_DELAYED = r2;
>
> > // Both the L and R data are assumed to arrive at this module
> > // at the same time, and to be available at the rising
> > // edge of the provided LRCLK. Since LRCLK is the output
> > // waveform used for synching data, this is a valid assumption.
> > // L_data and R_data _must_ be set up some time before the
> > // positive edge of LRCLK.
>
> > always @(posedge LRCLK) begin
> > L_DATA_STORAGE <= L_DATA;
> > R_DATA_STORAGE <= R_DATA;
> > shift_counter <= 31; // Reset count-down counter
> > end
>
> > always @(negedge LRCLK)
> > shift_counter <= 31; // Reset count-down counter
>
> > // Output data is assigned here. DATAOUT is assigned the value of
> > // 0 if our counter has gone past the data's LSB. The DAC's
> > // left-channel data is supplied when LRCLK is high, and its
> > // right-channel data is spplied when LRCLK is low.
>
> > always @(posedge SCLK_DELAYED) begin
> > if(shift_counter < 8)
> > DATAOUT = 0;
> > else if(LRCLK == 1)
> > DATAOUT = L_DATA_STORAGE[shift_counter-8];
> > else
> > DATAOUT = R_DATA_STORAGE[shift_counter-8];
> > end
>
> > // The timing of this is such that shift_counter counts down
> > // from 32 to 0 twice in each LRCLK - once per 'side'. This is
> > // decremented after the output has already been assigned a value.
> > // shift_counter could also be decremented on the falling edge of
> > // SCLK_DELAYED without changing the result.
>
> > always @(negedge SCLK) begin
> > shift_counter <= shift_counter-1;
> > end
>
> > endmodule
>
> You adjust shift_counter in multiple processes (always @), which won't do.
> You should only have 1 clocked process modifying shift_counter.
> With all clocks being synchronously divided versions of CLK = 49.152MHz, you
> should substitute the other clocks by "enable"/edge detect signals clocked
> on CLK. The low frequency clocks can still be made available/imported from
> the external world.
>
> Regards,
> Alvin.

Also in XST every clocked register needs to fit a flip-flop template.
You can't have posedge and negedge of the same clock for example, even
if you place the code in the same always block.  In Xilinx parts dual
clocked flip-flops (DDR flops) only exist in the I/O blocks and must
be instantiated, not inferred.  The standard template for an
asynchronous set/reset flip-flop looks like:

always @ (negedge SCLK or posedge LRCLK)
if (LRCLK) // active high async reset on LRCLK
  begin
    shift_counter <= 31; // Reset count-down counter
  end
else // negedge SCLK
  begin
    shift_counter <= shift_counter-1;
  end

Regards,
Gabor

Article: 131186
Subject: Re: Intel plans to tackle cosmic ray threat (actually they have been working on it for at least five years...austin)
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 14 Apr 2008 23:35:55 +0100
Links: << >> << T >> << A >>

cs_posting@hotmail.com wrote:
> On Apr 8, 4:27 pm, austin <aus...@xilinx.com> wrote:
>
>> The direction is predominately "up" as the flux falls off away from
>> "up" (towards the sky) as the neutrons are absorbed by the
>> atmosphere at oblique angles.
>
> That would seem to suggest the semiconductor dies should always be
> oriented in the vertical plane -
> substantial reduction in cross sectional exposure, plus anything that
> does hit it might affect a longer
> "scratch" of circuitry rather than just a point?   Assuming I guess
> that the interaction isn't entirely confined to discrete points along
> the flight path by quantum effects.

Hmm, because it's a flux, isn't the only thing that matters the volume of 
the die? Edge on to the main direction means there's less exposed area, but 
much more depth to travel through for the particles that do hit. Is it true 
that the particles/per unit volume remain the same no matter what the 
orientation is? Interesting...

Perhaps upside down is the best orientation so the lead in the solder stops 
some stuff. :-) Oh yeah, damn you
RoHS!

Cheers, Syms.

Article: 131187
Subject: Re: case statements- verilog to vhdl
From: FP <FPGA.unknown@gmail.com>
Date: Mon, 14 Apr 2008 16:01:44 -0700 (PDT)
Links: << >> << T >> << A >>

On Apr 14, 4:01=A0pm, Mike Treseler <mike_trese...@comcast.net> wrote:
> FP wrote:
> > From design point of view I am not sure if I should be putting them in
> > 2 seperate process statements.
>
> No. One verilog block is one vhdl process.
>
> > My question is
> > 1) Is the VHDL equivalent of the above, 2 case statements in one
> > process or 2 different processes with 1 case each?
>
> one process
>
> > 2) The above is similar to an FSM. One case statement is executing the
> > present command, while the other is completing the last command. Any
> > idea on how this should be converted to VHDL?
>
> Did the verilog version work?
>
> =A0 =A0 =A0 =A0 =A0-- Mike Treseler

The verilog code works but I havent deisnged it. So, I am not sure how
its implementation in VHDL woould be.

Article: 131188
Subject: Re: case statements- verilog to vhdl
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 14 Apr 2008 16:20:38 -0700
Links: << >> << T >> << A >>

FP wrote:

> The verilog code works but I havent deisnged it. So, I am not sure how
> its implementation in VHDL woould be.

Unless you post the code, neither am I.

          -- Mike Treseler

Article: 131189
Subject: Re: 64 bit WebPack
From: <steve.lass@xilinx.com>
Date: Mon, 14 Apr 2008 17:24:02 -0600
Links: << >> << T >> << A >>

ISE on 64 bit Windows runs quite a bit slower and uses more memory than the 
32 bit executables. That's why we now install the 32bit executables together 
with the 64bit executables on a 64bit system.

However, 64bit Linux runs slightly faster than 32bit Linux.

Steve

"David Brown" <david@westcontrol.removethisbit.com> wrote in message 
news:4803021c$0$14994$8404b019@news.wineasy.se...
> Eric Smith wrote:
>> Roger wrote:
>>> Will there be a 64 bit WebPack version of ISE in the near future?
>>
>> Is it really necessary?  WebPack doesn't support parts large enough
>> to exhaust the memory avialable in the 32-bit world.
>
> Processors using the amd64 ISA have a number of advantages other than just 
> access to larger amounts of memory.  They've got more general purpose 
> registers, 64-bit arithmetic, and slightly less legacy baggage. So for 
> some tasks, a program compiled for 64-bit windows/*nix will run noticeably 
> faster than one compiled for 32-bit mode - even if it does not use much 
> memory.  I have no idea if that applies to ISE, however.

Article: 131190
Subject: Re: 64 bit WebPack
From: Eric Smith <eric@brouhaha.com>
Date: Mon, 14 Apr 2008 17:41:05 -0700
Links: << >> << T >> << A >>

I wrote:
> Is it really necessary?  WebPack doesn't support parts large enough
> to exhaust the memory avialable in the 32-bit world.

David Brown wrote:
> Processors using the amd64 ISA have a number of advantages other than
> just access to larger amounts of memory.  They've got more general
> purpose registers, 64-bit arithmetic, and slightly less legacy
> baggage. So for some tasks, a program compiled for 64-bit windows/*nix
> will run noticeably faster than one compiled for 32-bit mode - even if
> it does not use much memory.  I have no idea if that applies to ISE,
> however.

I would say "measurably faster" rather than "noticeably faster".  But I
would still claim that it makes little difference for WebPACK.  The 32-bit
version should be fine for all the supported devices.

Article: 131191
Subject: Re: Xilinx tech Xclusive
From: Eric Smith <eric@brouhaha.com>
Date: Mon, 14 Apr 2008 17:44:41 -0700
Links: << >> << T >> << A >>

Symon wrote:
> Why not leave the TechXclusives on the website until they've been turned 
> into whatever 'corporate image thing' the new VP has decided on?

I second that.  No matter how well-intentioned the plan is, it seems
likely that some useful information in older TechXclusives will be
lost.  Xilinx still has old issues of Xcell online, so it's hard to
understand what problem was caused by having old TechXclusives online.
Had I known they were going away, I would have archived them myself.
(Hmmm... guess I'd better do that with the Xcell issues!)

Eric

Article: 131192
Subject: Re: Intel plans to tackle cosmic ray threat (actually they have been working on it for at least five years...austin)
From: "Marty Ryba" <martin.ryba.nospam@verizon.net>
Date: Tue, 15 Apr 2008 01:14:27 GMT
Links: << >> << T >> << A >>


"Symon" <symon_brewer@hotmail.com> wrote in message 
news:fu0m8u$vcj$1@aioe.org...
> cs_posting@hotmail.com wrote:
>> On Apr 8, 4:27 pm, austin <aus...@xilinx.com> wrote:
>>> The direction is predominately "up" as the flux falls off away from
>>> "up" (towards the sky) as the neutrons are absorbed by the
>>> atmosphere at oblique angles.
>>
>> That would seem to suggest the semiconductor dies should always be
>> oriented in the vertical plane -
>> substantial reduction in cross sectional exposure, plus anything that
>> does hit it might affect a longer
>> "scratch" of circuitry rather than just a point?   Assuming I guess
>> that the interaction isn't entirely confined to discrete points along
>> the flight path by quantum effects.
>
> Hmm, because it's a flux, isn't the only thing that matters the volume of 
> the die? Edge on to the main direction means there's less exposed area, 
> but much more depth to travel through for the particles that do hit. Is it 
> true that the particles/per unit volume remain the same no matter what the 
> orientation is? Interesting...

    I forget where I saw the information, it may have been in a briefing 
from some of our rad-hard experts in Manassas (BAE Systems, proud producer 
of the RAD750 PowerPC and RAD6000 processors). There are some 
direction-dependent effects that are just being recognized and dealt with as 
circuit dimensions shrink. I think the V4 is seeing some of these issues 
crop up...the "single event upsets" are no longer confined to a single 
circuit element especially if the rays come in from an oblique angle. The 
stream of charges/holes created by a particle floods multiple cells IIRC. 
Not very many rad-tolerant designs deal with this concept yet (correlated 
upsets in adjacent bits of the logic), though with smart floorplanning a 
design can probably mitigate this. Austin's comment about deliberately 
flipping one bit at a time and verifying performance does go out the window 
when you throw this curveball into the mix. Since the RAD750 is currently 
fabricated at 150nm (soon 120nm) this effect isn't important (yet), but when 
you look at 65nm circuits (1/4 the surface area per logic element) this 
effect is becoming noticed. Of course the performance you get from these 
denser circuits is why we keep plugging away at making it work. Both Xilinx 
and BAE Systems can share credit for the Mars Rover's endurance (a RAD6000 
is the main computer, and I think Austin described several smaller Xilinx 
parts in critical subsystems).

Comments, Austin? I'm looking at this second-hand so I'll defer to your 
obvious focus on this area.

Dr. Marty Ryba

Article: 131193
Subject: Xilinx JTAG Linux programming
From: Habib Bouaziz-Viallet <habib@rigel.systems>
Date: 15 Apr 2008 07:19:22 GMT
Links: << >> << T >> << A >>

Hi all !

i have been installing "libusb-driver.so" found
here http://rmdir.de/~michael/xilinx/ and it simply work fine with PCIII

I also recommend to read documentation on the web site and inside the
source package.

Thanks to Uwe !

HTP, habib

Article: 131194
Subject: Re: DOS script file to synthesize a VHDL design
From: "HT-Lab" <hans64@ht-lab.com>
Date: Tue, 15 Apr 2008 08:04:45 GMT
Links: << >> << T >> << A >>


"Sue" <sudhangi@gmail.com> wrote in message 
news:a6b7da33-81c8-4780-bbfd-822ceade089e@s39g2000prd.googlegroups.com...
> Does anyone know how can I get started on making a DOS script file to
> synthesize a VHDL design. I tried understanding something from:
> http://toolbox.xilinx.com/docsan/xilinx5/pdf/docs/xst/xst.pdf
>
> But I still need more help.
> Can someone please tell me the sequence which I should follow.
>
> Thanks

This is how Mentor's HDL Designer does it (auto generated)

syn.bat:

"C:/Xilinx/bin/nt/xst.exe" -intstyle xflow -ifn cpu86.xst -ofn cpu86.syr

cpu86.syr: output log file

cpu86.xst: contains the project as shown below (note not all synthesis 
settings shown):

set -xsthdpdir ./xst
run
-ifn cpu86.prj
-ofn cpu86
-top cpu86
-p xc3s500e-cp132-4
-uc cpu86.xcf

cpu86.prj: contains the file list

vhdl cpu86 proc_rtl.vhd
vhdl cpu86 cpu86_struct.vhd

cpu86.xcf: contains the UCF settings:

NET "clk" TNM_NET = "clk";
TIMESPEC "TS_clk" = PERIOD "clk" 0.025 us;

Good luck,

Hans
www.ht-lab.com

Article: 131195
Subject: Re: 64 bit WebPack
From: David Brown <david@westcontrol.removethisbit.com>
Date: Tue, 15 Apr 2008 10:35:22 +0200
Links: << >> << T >> << A >>

steve.lass@xilinx.com wrote:
> ISE on 64 bit Windows runs quite a bit slower and uses more memory than the 
> 32 bit executables. That's why we now install the 32bit executables together 
> with the 64bit executables on a 64bit system.
> 
> However, 64bit Linux runs slightly faster than 32bit Linux.
> 

That's interesting - I wonder if it is related to the different 64-bit 
models used by windows and linux (windows uses 32-bit int and long, with 
only 64-bit for pointers, while linux has 32-bit int and 64-bit long). 
If the ISE code takes advantage of 64-bit longs on linux, but does not 
use the equivalent "long long" or "__int64" type on windows, then that 
might explain the difference (64-bit pointers are often slower than 
32-bit pointers, so that a pointer-heavy 64-bit executable might be 
slower than a 32-bit version).

Article: 131196
Subject: Re: Which to learn: Verilog vs. VHDL?
From: "RCIngham" <robert.ingham@gmail.com>
Date: Tue, 15 Apr 2008 05:17:16 -0500
Links: << >> << T >> << A >>


>which would be more useful to learn in the industrial world: Verilog
>or VHDL?

In Europe (including UK) VHDL is more commonly used.

In USA Verilog is prevalent.

However, SystemVerilog is gradually gaining ground everywhere, and
Verilog-2001 is a subset of SV.

It is probably very difficult to learn both simultaneously...

Article: 131197
Subject: Re: DOS script file to synthesize a VHDL design
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Tue, 15 Apr 2008 11:35:12 +0100
Links: << >> << T >> << A >>

On Mon, 14 Apr 2008 10:43:52 -0700 (PDT), Sue <sudhangi@gmail.com> wrote:

>Does anyone know how can I get started on making a DOS script file to
>synthesize a VHDL design. I tried understanding something from:
>http://toolbox.xilinx.com/docsan/xilinx5/pdf/docs/xst/xst.pdf
>
>But I still need more help.
>Can someone please tell me the sequence which I should follow.
>

If you have synthesised under ISE, you can look at the command log file for
examples; copy and paste these (modifying if necessary) to create your own
script.

- Brian

Article: 131198
Subject: Simulation tools for Xilinx ISE
From: Michael <nleahcim@gmail.com>
Date: Tue, 15 Apr 2008 06:15:09 -0700 (PDT)
Links: << >> << T >> << A >>

Howdy - I'm just getting started with FPGAs. In college I remember we
used ModelSim with ISE for FPGA simulation. We were able to get a
license through our school for free. Like a fool I no longer have that
license, so what free options are out there? I saw that there is
something called ModelSim Xilinx Edition III Starter (http://
www.xilinx.com/ise/mxe3/download.htm). I can't tell if that is just a
limited feature package, or a time limited package. Is that what I
want? Or is there something else I should be looking at?

Thanks!

-Michael

Article: 131199
Subject: Re: 64 bit WebPack
From: "Roger" <rogerwilson@hotmail.com>
Date: Tue, 15 Apr 2008 14:53:58 +0100
Links: << >> << T >> << A >>

Thanks for the comments in response to my initial query. It sounds like 
there won't be a 64 bit Webpack - which is a shame as the devices covered by 
it are sufficient for my work and I've got a PC with Vista 64 bit on it!

Rog.

"Roger" <rogerwilson@hotmail.com> wrote in message 
news:Yv-dneipyM86-GLaRVnyjwA@plusnet...
> Will there be a 64 bit WebPack version of ISE in the near future?
>
> Rog.

Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources

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

Custom Search