EDK : FSL macros defined by Xilinx are wrong

Brad,

As far as I recall, the speed grade affects only timing analysis (xilinx
people would correct me if i am wrong).

Downloading a bit file which was synthesized with a different speed grade
only is ok.

But if the device is different in size, then you have to resynthesize it, in
which case a suitable script would do the job.


Vladislav

"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:11et3q5p4gbnn22@corp.supernews.com...
I have a board with three Spartan3s on it.
Right now, under sources in project, I have
the project name, then xc3s400-4pq208,
and under that
top1-behavioral(top1.vhd),
top2-behavioral(top2.vhd),
top3-behavioral(top3.vhd)

and stuf under those like the top1.ucf, etc.

So what happens if one of the Xilinx parts
gets upgraded or downgrade in speed or
size? Can I assign the xc3s400 spec to
each top level design?

Brad
Click to expand...
 
Brad,

There are two types of reset. One, hardware reset, is typically sourced by
an external pin. Two, software reset, is typically sourced by a bit written
by CPU & any other host controller. It all depends on what you are up to.

Sometimes, you might want to reset parts of the design upon some
synchronization reached or something like this.

Vladislav


"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:11estoihe350a2f@corp.supernews.com...
Up to now, I have been doing much of my work with ModelSim and
a BMP file reader and writer. Most of my VHDL designs have clk
and reset. I know where to attach the clk but what do I use for
reset. An external pin? The Done pin? Or a DCM lock signal?

Brad Smallridge
b r a d @ a i v i s i o n . c o m
Click to expand...
 
Pavel,

I can see at least one fundamental problem, which is registered output. No
need for references. Simply keep in mind that usually, bidirectional bus
with tri-state is implemented without FFs, because when you sample 1'bz, the
result is always 'X', BY LAW.

Try the following :

// sample dout
assign dout = en ? dout1 : 1'bz;
assign din = dout;

Hope this helps.

Vladislav

"Telenochek" <interpasha@hotmail.com> wrote in message
news:1122919805.341703.215660@g14g2000cwa.googlegroups.com...
Hello everyone!
I am having a problem in ModelSim XE 5.8c with a very simple
bidirectional bus.
ModelSim outputs a bunch of XXXX's where its supposed to output data.
I am using test bench waveforms with Xilinx ISE 6.303i.

Basically there are only 3 signals: the bidir. bus, wr_enable and clk.
The idea behind this simple code is:
if WR_EN is HIGH -> store bus data into a flip-flop on next clock edge.

else WR_EN is LOW -> output a constant value on the bus (in practice, I
want to output something more useful, of course.)

Unfortunately, ModelSim outputs X's (don't cares) for every bit where
the data in flip-flop conflicts with the constant.
Let's say that 11110000 was stored in the flip-flop when WR_EN was
high.
And suppose that the constant to put on the bus is 00110000, when WR_EN
goes low.
When WR_EN actually does go low, ModelSim will output XX110000 instead
of 00110000.

I think the problem might be with the way I designed the bus with VHDL.
But I can't figure out where the problem is, and the code is VERY
simple.
Any help on this and maybe references to reading materials on
bidirectional/tristate bus implementation in VHDL would be highly
appreciated!
Thanks,
Pavel

Here is the code:
------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
------------------------------
ENTITY bidir_bus IS
PORT(
bidir : INOUT STD_LOGIC_VECTOR (7 DOWNTO 0);
WR_en, clk : IN STD_LOGIC);
END bidir_bus;
------------------------------
ARCHITECTURE Behavioral OF bidir_bus IS
SIGNAL a : STD_LOGIC_VECTOR (7 DOWNTO 0); -- DFF that stores
-- value from input.
BEGIN
PROCESS (WR_en, clk)
BEGIN
IF( WR_en = '1') THEN
bidir <= "ZZZZZZZZ";
IF(clk'EVENT and clk='1') THEN
a <= bidir;
END IF;
ELSE
bidir <= "11110000"; -- simply output a constant on the bus
-- of course, in practice I would like to
-- output something else.
END IF;
END PROCESS;
END Behavioral;
------------------------------
Click to expand...
 
No, Symon.

I am afraid not, my problem is a real problem. It's something very simple
and fundamental.
I am switching between the two clocks when I loop one data path to another.

But thanks, appreciate it. Can you think of anything else?

Vladislav.


"Symon" <symon_brewer@hotmail.com> wrote in message
news:42ef578f$0$18641$14726298@news.sunsite.dk...
"Vladislav Muravin" <muravinv@advantech.ca> wrote in message
news:h5pHe.780$z91.148816@news20.bellglobal.com...

I have a V2 3000 device, and I am using BUFGMUX, the one located at P7
location (for this synthesis, I do not lock them). This BUFGMUX guy
multiplexes between one external and one internal clock. I output all 4
signals of BUFGMUX on the test pins and I see that when S is '1', the
output is not equal to I1 input !!!
I verify at least by FPGA Editor that the connections of BUFGMUX are ok.

So, I am going for another board with another FPGA and I will also check
that the pins are not shorted, but any other suggestions from everybody
are always welcome.

Here's a suggestion, in the V2 datasheet it says that "As long as the
presently selected clock is High, any level change of S has no effect .".
Is that your problem?
Cheers, Syms.
Click to expand...
 
Latest version supports up to XC3S1500. XC3S400 has been support since
6.1-6.3 time.

--
John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development
Board.
http://www.enterpoint.co.uk

"Chris Carlen" <crcarleRemoveThis@BOGUSsandia.gov> wrote in message
news:dclt200130k@news3.newsguy.com...
Hi:

I am reading the FAQ on Spartan3 here:

http://www.xilinx.com/products/spartan3/faq105_s3.pdf

which says only XC3S50 is supported by WebPack 5.2i. I realize this is an
old version (though the one I am still using since I had trouble with
6.1i). Now we are at 7.1i, which indicates support for Spartan3 of course
here:

http://www.xilinx.com/ise/logic_design_prod/webpack.htm

but doesn't indicate the details about whether it supports larger Spartan3
devices or not.

Specifically, I am considering XC3S400.

Does WebPack 7.1i support that or do I need to start spending $$$ ?


Thanks for input.


Good day!


--
_______________________________________________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarleRemoveThis@BOGUSsandia.gov
NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.
Click to expand...
 
Baxter wrote:
I inherited some code for the Actel fpga.
I need two things:
1 - to be able to read the code/project and determine what it does
2 - to be able to revise/maintain the code.

I would like recommendations as to what toolchain to port this code to.
Money is an issue - ROI is quite low.
Click to expand...
If the code is a netlist and you don't know
what it does, I see little value in maintaining it.

If it is generic RTL code with a testbench,
you can make modifications and test them, and
port to any fpga you like.

-- Mike Treseler
 
I'm new to this kind of programming - I don't know what "netlist" or "RTL"
are.

I have a general idea what the code does, I need to find out the
nitty-gritty details. As it stands now, I have a binary file I can use to
burn chips, but no ability to maintain or extend the code. I'd like to port
the design to a slightly different platform -- I'd still be using the same
chip, but likely the chip software would have to change slightly.

It's got lots of different files, including some .vhd. I was hoping to find
someone with lots of Actel experience.

--
---------------------------------------------------------------------
DataGet & PocketLog www.dataget.com
Data Collectors www.baxcode.com
--------------------------------------------------------------------



"Mike Treseler" <mtreseler@gmail.com> wrote in message
news:BPSdnb1oosj_g23fRVn-vA@comcast.com...
Baxter wrote:
I inherited some code for the Actel fpga.
I need two things:
1 - to be able to read the code/project and determine what it does
2 - to be able to revise/maintain the code.

I would like recommendations as to what toolchain to port this code to.
Money is an issue - ROI is quite low.

If the code is a netlist and you don't know
what it does, I see little value in maintaining it.

If it is generic RTL code with a testbench,
you can make modifications and test them, and
port to any fpga you like.

-- Mike Treseler
Click to expand...
 
"Baxter" <lbax02.spamguard@baxcode.com> schrieb im Newsbeitrag
news:11f0f3eom8odk97@corp.supernews.com...
I'm new to this kind of programming - I don't know what "netlist" or "RTL"
are.

I have a general idea what the code does, I need to find out the
nitty-gritty details. As it stands now, I have a binary file I can use
to
burn chips, but no ability to maintain or extend the code. I'd like to
port
the design to a slightly different platform -- I'd still be using the same
chip, but likely the chip software would have to change slightly.

It's got lots of different files, including some .vhd. I was hoping to
find
someone with lots of Actel experience.

--
---------------------------------------------------------------------
DataGet & PocketLog www.dataget.com
Data Collectors www.baxcode.com
--------------------------------------------------------------------
Click to expand...
well the .VHD are source files, if all the project is on .VHD files then you
have no problems. if part of the design is not, eg is in compiled files or
in schematic files not readable by available tools then you have more
problems.

Antti
 
Hi,

I have forgotten to mention that the traces between the FPGA and the
transceiver are routed as very loosely coupled traces where each trace
has a 50 ohm characteristic impedance. Each trace is about 5 cm long.

Best regards,

JF
 
"Marc Randolph" <mrand@my-deja.com> wrote in message
news:1123071787.753397.21140@z14g2000cwz.googlegroups.com...
In your other message, you mentioned that the nets "are routed as very
loosely coupled traces where each trace has a 50 ohm characteristic
impedance". I'd think you'd want a fairly tightly coupled 100 ohm
differential pair. How loosely are they coupled? Are the _p and _n
legs close to the same length?

Hi Marc,
Click to expand...
The coupling between them doesn't matter if the individual lines are 50 ohms
and the propagation time. How can the electricity know the difference
between that and a 100 ohm diff pair, or indeed, all the hybrid combinations
in between?

JF,
You should check the datasheet or call the manufacturer to make sure you
don't need the put any DC bias on the optics' rx CML port. Normally it's
something like Vicm, input common mode voltage.

Cheers, Syms.
 
"Symon" <symon_brewer@hotmail.com> wrote in message
news:42f0d979$0$18645$14726298@news.sunsite.dk...
The coupling between them doesn't matter if the individual lines are 50
ohms and the propagation time is the same for each.
Click to expand...
Whoops, typo!
 
<usenet_10@stanka-web.de> wrote in message
news:1123053054.887144.273240@o13g2000cwo.googlegroups.com...
HI,

based on your other answer I understand you have a .adb file.
Click to expand...
I do have a .adb file - along with a host of others. I've got
subdirectories labeled "design_definition", "simulator_build", etc.

This is the actel database which should be useable in the newer
versions of actel designer software (When having a very old version you
might lost your pinout).
I hope you didn't mean a .afm file which is only the programming file
for the Fpga and will be (nearly [1]) complete useless.
Click to expand...
I do have a .afm file which I sent off to the Actel distributor when I
ordered more chips.

The designer software is available as silver edition for free. This
edition is OK for smaller devices.
Click to expand...
Well, how small? I'm using the eX64 (64 dedicated flip-flops, 3000 system
gates)

The database contains the netlist which can be exported. But without
having any knowledge of rtl and netlist you out yourself as someone who
should not even think to modify the netlist to get the desired results.
Click to expand...
No "outing" about it - I'm a raw beginner at embedded programming. I'm
trying to make sense of what I've got and to determine what I need to do.
Among other things, I'm trying to determine if I should continue with this
basic design or to switch to an entirely different chip. (a business
decision based on technical aspects.)

Start searching .vhd or .v files containing the rtl code (register
transfer level).
The IMHO better way for you would be starting to learn how to design
digital cirquits and rebuild the design from scratch.
Click to expand...
I've got the book "VDHL Programming by example". I don't know if any of the
book's tools would be useable.
bye Thomas

[1] Buying a good support from Actel
Click to expand...
As I indicated, the ROI is VERY bad at this point.
 
http://home.comcast.net/%7Emike_treseler/uart.vhd
Click to expand...
Wow, that's an interesting use of procedures to automatically
restructure a program.

I brought the question of async vs. sync reset to the group awhile ago,
and someone told me (they should harp in here to get credit), that with
an async reset you may have metastable issues when your reset goes
inactive, which sort of defeats the purpose of having a reset. So this
sold me on sync resets, end of story.

When does a CPU know when to reset the FPGA? PowerUp timing
delay? I am using a Cypress USB chip which has some interesting
PowerUp ennumeration and renumeration issues if anyone has any
experience with this sort of thing.

Brad
 
On Wed, 3 Aug 2005 15:15:22 -0700, "Brad Smallridge"
<bradsmallridge@dslextreme.com> wrote:

http://home.comcast.net/%7Emike_treseler/uart.vhd

Wow, that's an interesting use of procedures to automatically
restructure a program.

I brought the question of async vs. sync reset to the group awhile ago,
and someone told me (they should harp in here to get credit), that with
an async reset you may have metastable issues when your reset goes
inactive, which sort of defeats the purpose of having a reset. So this
sold me on sync resets, end of story.
Click to expand...
Actually this is a false compromise. There is a perfectly safe way of
synchronizing the reset to your local cock(s) so that there is no
chance of metastability regardless of the reset release time. This way
you can continue to use async resets.
 
I had the similar problem. My solution is to change the C3 value to 68pF
and R11 value to 47 ohm. this will solve your problem.
 
On 4 Aug 2005 13:17:10 -0700, "Brandon" <killerhertz@gmail.com> wrote:

Actually, this syntax was ok:
port map (... P => unsigned(S) ...)

While this was not:
port map (... unsigned(A) => B ...)
Click to expand...
ok - both versions should be absolutely fine, assuming
A is an output port of course. Both forms were made
legal in VHDL-93 (in VHDL-87 it would have been necessary
to write your own function, something like "my_unsigned",
so that the conversion is a function call rather than an
array type conversion)

I don't understand why they haven't fixed this...
Click to expand...
Not enough people shouting about it, I guess.

Is there any sort of
option to toggle VHDL-93 syntax?
Click to expand...
You must have VHDL-93 enabled already, otherwise the input-port
conversion would also have been illegal.

If you don't mind, could you explain the wrapper workaround? I made the
changes manually myself, but that involved creating a duplicate signal
to perform the type conversion on. This is quite sloppy imo, and I
dislike having to tailor my code to a specific tool.
Click to expand...
Well... the code you end up with will work in any tool OK, it's
just that it is tiresome to do. I wasn't suggesting anything
different - just another layer of module instantiation so that
the conversion is not visible in the top-level module:

entity Original is
port (P: in unsigned(...); Q: out std_logic_vector(...));
end;

entity Wrapper is
port (P: in std_logic_vector(...); Q: out unsigned(...));
end;
architecture Hack of Wrapper is
signal QU: unsigned(...);
begin
Original_Instance: entity work.Original(arch)
port map (P => unsigned(P), Q => QU);
Q <= std_logic_vector(QU);
end;

Now, when you instantiate Wrapper in your top-level module,
no type conversion is needed. I'm sure this is exactly
what you have already done - I'm merely suggesting the
wrapper module as a way of localising the type conversion
so that it doesn't pollute the architecture of the
enclosing module.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
Symon wrote on 05.08.2005 11:45:
This is lazy I know, but could you post a link to point me at the SI-list so
I can hunt down the stuff you mention?
http://www.si-list.org :)
Click to expand...

cu,
Sean
 
In a way yes and it's safe to do. You don't register the reset signal
though. Assume you have an active low reset. You connect input of a
flop to 1 and connect its async reset input to the reset io pin, a
second flop takes the output of the first as input and it's also async
reset by the io pin. These are clock by your local clock (of course
you have to make sure that for every clock domain in your design, you
repeat this process).
Click to expand...
OK. Are you doing this with Unisim components? Or can the
XST infer all this through VHDL? And then does the synched
reset from the second flop then connect to some global reset?
And then how do you check that the synthesizer is correctly
inferring to use the synched reset signal?

Brad
 
"Brad Smallridge" wrote:

In a way yes and it's safe to do. You don't register the reset signal
though. Assume you have an active low reset. You connect input of a
flop to 1 and connect its async reset input to the reset io pin, a
second flop takes the output of the first as input and it's also async
reset by the io pin. These are clock by your local clock (of course
you have to make sure that for every clock domain in your design, you
repeat this process).

OK. Are you doing this with Unisim components? Or can the
XST infer all this through VHDL? And then does the synched
reset from the second flop then connect to some global reset?
Click to expand...
Try something like this:

Process(clk,resetin)
begin
if resetin = '1' then
reset1 <= '1';
reset2 <= '1';
elsif rising_edge(clk)
reset1 <= not dll_lock;
reset2 <= reset1;
end if;
end process;

-- one of many processes
Rest_of_logic: process(clk)
begin
if rising_edge(clk) then
if reset = '1' then
-- set reset conditions where needed
else
-- normal operation
end if;
end if;
end process;

Output_needing_forced_off_during_reset: process(regular_oe, reset, d)
begin
if regular_oe = '0' or reset = '1' then
OUTPIN <= 'Z';
else
OUTPIN <= d;
end if;
end process;

And then how do you check that the synthesizer is correctly
inferring to use the synched reset signal?
Click to expand...
FPGA_editor.


--
Phil Hays
Phil-hays at comcast.moc (remove moc and add net) should work for
email
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top