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

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Messages from 142300

Article: 142300
Subject: Ethernet PHY and Endianness
From: Gints <reganireland@gmail.com>
Date: Sun, 2 Aug 2009 21:12:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
Good Afternoon,

I am writing a simple UDP core to send data from a Xilinx S3E to PC
via Ethernet sending UDP packets, and have a query relating to
endianness and the PHY: LAN83c185: http://www.smsc.com/media/Downloads_Public/Data_Sheets/83c185.pdf

My understanding is that the byte order is Big Endian, thus the most
significant byte first: Thus an IP would be sent:
C0 then A8 then 00 then 01 for the IP 192.168.0.1

I also read that each byte must be sent with the LEAST SIGNIFICANT
NIBBLE first: Thus in terms of nibbles, that IP would be:
0 then C then 8 then A then 0then 0 then 1 then 0

My confusion comes from the interface to the PHY. It is a 4 bit bus,
so I obviously have to send one nibble at a time.  I understand this
should be the least significant nibble of every byte followed by the
more significant nibble. My question is the BIT ORDER of each of the
nibbles. I understand that ethernet bitstream is the LEAST SIGNIFICANT
BIT of each byte. Basically I am not sure if I should send the nibble
for the PHY in its normal format, or if I should bit reverse it:

ie: For nibble A, do i send: "1010" to PHY pins 3:0, or do I send
"0101" to PHY pins 3:0. I cannot find out whether the PHY handles the
bit order of each nibble in the way it handles all the NRZI stuff etc.

Sorry for the poor wording, but I find endianness is one of things so
hard to explain etc.
Gints

Article: 142301
Subject: Re: [newbie] Verilog test bench with automatic verification
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Mon, 03 Aug 2009 04:39:24 -0500
Links: << >>  << T >>  << A >>
I've never actually used webise so I cant really say. You may be best to
just stick with verilog at the moment if you are just doing it as a hobby.
To get system verilog functionality you would probably have to spend some
money on more expensive tools.

Cheers

Jon

Article: 142302
Subject: Re: Xilinx 3E design programs fine with 500E but fails with 250E
From: Steve <srkh28@gmail.com>
Date: Mon, 3 Aug 2009 03:46:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Brian,


> =A0- Set the FPGA mode pins to JTAG mode, not to SPI mode, when
> =A0 =A0programming over JTAG using the Impact SPI flash core.

--> I can try this, but, sorta defeats having a bootable FPGA. The
500E version works fine without needing to do this.


> =A0 ( Otherwise the FPGA SPI boot process can fight with the JTAG port )

--> I think it tries 3 times to load from spi and then gives up.

>
> =A0- Change the JTAG clock rate used by Impact to one of the slower
> speeds,

--> Its not a JTAG related issue, but I have tried this for sanity. I
set the cable speed to its slowest (750Kbps) - still no go.

> =A0 =A0and make sure it can reliably run the JTAG loopback test at that
> rate

--> Loop backworks fine a 10MHZ for 1M test cycles - all passes ok, so
communicating with the device is 100% ok - allways has been.

Talking to the FPGA has always been fine - you can download projects
and things work great. the only problem is, the FPGA is unable to
write to its flash using xilinx precompiled cores, xc3s250e_spi.cor.
this spi bridge core is unique to each device and each package. The
500E PQ208 version works beautifully - but the 250E PQ208 version
seems to be a bug fest.

Is the source available for these? I expect I will have to write my
own, or bite the bullet and leave the spartan and go with altera.

steve



Article: 142303
Subject: Re: Xilinx 3E design programs fine with 500E but fails with 250E
From: Steve <srkh28@gmail.com>
Date: Mon, 3 Aug 2009 04:00:30 -0700 (PDT)
Links: << >>  << T >>  << A >>

I just went to Xilinx's website to log a case with them.

Xilinx now screen who they feel is suitable for logging cases, and
those who they feel are not - takes a day for them to decide after you
request to log a case.

I think their patent is about to run out... I feel a change of guard
not far off.

Article: 142304
Subject: Re: Single ended LVDS into FPGA
From: gabor <gabor@alacron.com>
Date: Mon, 3 Aug 2009 06:03:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 1, 5:29=A0pm, "BobW" <nimby_GIMME_SOME_S...@roadrunner.com>
wrote:
> "Nico Coesel" <n...@puntnl.niks> wrote in message
>
> news:4a749265.358227234@news.planet.nl...
>
>
>
> > "BobW" <nimby_GIMME_SOME_S...@roadrunner.com> wrote:
>
> >>"Nico Coesel" <n...@puntnl.niks> wrote in message
> >>news:4a7477d0.351422078@news.planet.nl...
> >>> Some food fo thought:
>
> >>> I'm working on a new design in which I need to bring 64 LVDS (250Mbps
> >>> each/ 125MHz fmax) lines into a Spartan3 FPGA. The distance between
> >>> the source and the FPGA is less than 2" / 5cm. Ofcourse there is a
> >>> solid ground plane underneath the signals (the board will have at
> >>> least 4 layers).
>
> >>> I'm wondering if I can save a lot of pins if I feed the LVDS signals
> >>> single ended into the FPGA (terminate the pair close to the FPGA and
> >>> leave one end dangling). I could bias the Vref pins on the FPGA to th=
e
> >>> centre point of the LVDS signal. If I set the input pin type to GTL i=
t
> >>> should work on paper. The LVDS signal has enough swing to exceed the
> >>> minimum signal amplitude.
>
> >>> Anyone ever tried this?
>
> >>> --
>
> >>The thing that would concern me is how to guarantee that VREF is held a=
t
> >>the
> >>centerpoint (common mode) of the signal swing. If you were only dealing
> >>with
>
> > The datasheet of the source chip specifies that. I more or less assume
> > the source chip has the same centerpoint on all outputs.
>
> >>one pair then you get tricky and extract the common-mode point from tha=
t
> >>pair - assuming that the signal was always transitioning. Knowing that
>
> > IMHO you don't need a signal that is always toggling. If you connect a
> > resistor to each leg of the pair and a capacitor to ground (resistor
> > divider between the two legs) then the voltage across the capacitor
> > should be the centre voltage no matter what the LVDS signal looks
> > like.
>
> Ahhh, yes. Silly me.
>
> I hope this works out for you. I suspect it will if you adapt VREF to the
> true centerpoint of one of the signals and if all the driver's common mod=
e
> points stay fairly close to each other.
>
> If one of those pairs is a forwarded clock, and if you decide to do the V=
REF
> adapt technique, then I wouldn't use the clock line for that function. LV=
DS
> is not intrinsically source terminated (it's high impedance drive [curren=
t
> source]). So, if you get any type of end reflection it will eventually co=
me
> back toward that receiver. Data lines are somewhat forgiving. Clock lines
> are like women.
>
> Bob
> --
> =3D=3D All google group posts are automatically deleted due to spam =3D=
=3D

You should consider running both halves of each pair up to the
Spartan 3 and terminate with 100 ohms differential near the
pin.  This gets rid of the reflection issue although you end
up with more routing.  It also addresses another issue found
with most LVDS drivers that I've come across.  They are designed
to run into a 100 ohm differential load.  Very often they
won't work properly without the load.  What I see is that
the signal swing increases significantly without the load,
especially at low frequencies.  Then the switching delay
increases with the increased swing.  So if you have a data
bit that toggles on random clock edges, the clock to output
delay through the LVDS device will be longer after it has sat
at the same value for more than one clock period than
on edges where it toggled on the previous cycle.  This
second issue could be handled with the termination
resistor near the source, but once you have the extra
parts and routing, it seems reasonable to put the
resistor where it gives the best signal integrity.

Regards,
Gabor

Article: 142305
Subject: Re: Xilinx 3E design programs fine with 500E but fails with 250E
From: Mike Harrison <mike@whitewing.co.uk>
Date: Mon, 03 Aug 2009 15:53:01 +0100
Links: << >>  << T >>  << A >>

Have you verified the SPI chip against the file to identify whether it's a programming or FPGA load
issue. 

I just had a nightmare problem with a Lattice part where the tools would sometimes generate a file
that would run in the device via JTAG but not load from SPI PROM - it was very design-content and in
some cases device type dependent. The Lattice tools look VERY similar to ISE so I wonder if there
may be some connection...

Article: 142306
Subject: ucf and clock pin placement on Spartan 3E?
From: JanW <no_spam@thanks.net>
Date: Mon, 03 Aug 2009 20:57:11 +0300
Links: << >>  << T >>  << A >>
Hi,

I have a Spartan 3E (xc3s1200e-5) in fg320. Maybe something is wrong 
in the .ucf file because the placer says

WARNING:Route - CLK Net:extref_clk_pin_IBUFG is being routed on 
general routing resources. Please consider using a dedicated 
clocking routing resource. For more information on clock routing 
resources, see the target architecture's user guide.

And what I have in the .ucf file is

NET extref_clk_pin LOC = B10; ## pinheader J4, pin 10, GCLK_L12_P
NET extref_clk_pin IOSTANDARD = LVCMOS33;
NET extref_clk_pin TNM_NET = extref_clk_pin;
TIMESPEC TS_extref_clk_pin = PERIOD extref_clk_pin 200000 ps;

The ds312.pdf Spartan 3E FPGA Family Datasheet

http://www.xilinx.com/support/documentation/data_sheets/ds312.pdf

says on page 204 that the ball B10 is _supposed_ to be "GCLK" and 
pin name on 1200e is IO_L12P_0/GCLK6.

So why does Route say it routes over some non-clock route?

Perhaps there is something missing in the UCF?

  - Jan

Article: 142307
Subject: Re: ucf and clock pin placement on Spartan 3E?
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 3 Aug 2009 19:19:49 +0100
Links: << >>  << T >>  << A >>
JanW wrote:
>
> So why does Route say it routes over some non-clock route?
>
Jan,
Have you connected this net to anything in the FPGA fabric that isn't a 
dedicated clock input?
HTH., Syms. 



Article: 142308
Subject: Re: ucf and clock pin placement on Spartan 3E?
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Mon, 03 Aug 2009 13:27:36 -0500
Links: << >>  << T >>  << A >>
It could be the way that you have defined your clk in the hdl. Check that
it is connected to a clock input buffer. 

Jon

Article: 142309
Subject: Re: ucf and clock pin placement on Spartan 3E?
From: gabor <gabor@alacron.com>
Date: Mon, 3 Aug 2009 11:40:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 3, 1:57=A0pm, JanW <no_s...@thanks.net> wrote:
> Hi,
>
> I have a Spartan 3E (xc3s1200e-5) in fg320. Maybe something is wrong
> in the .ucf file because the placer says
>
> WARNING:Route - CLK Net:extref_clk_pin_IBUFG is being routed on
> general routing resources. Please consider using a dedicated
> clocking routing resource. For more information on clock routing
> resources, see the target architecture's user guide.
>
> And what I have in the .ucf file is
>
> NET extref_clk_pin LOC =3D B10; ## pinheader J4, pin 10, GCLK_L12_P
> NET extref_clk_pin IOSTANDARD =3D LVCMOS33;
> NET extref_clk_pin TNM_NET =3D extref_clk_pin;
> TIMESPEC TS_extref_clk_pin =3D PERIOD extref_clk_pin 200000 ps;
>
> The ds312.pdf Spartan 3E FPGA Family Datasheet
>
> http://www.xilinx.com/support/documentation/data_sheets/ds312.pdf
>
> says on page 204 that the ball B10 is _supposed_ to be "GCLK" and
> pin name on 1200e is IO_L12P_0/GCLK6.
>
> So why does Route say it routes over some non-clock route?
>
> Perhaps there is something missing in the UCF?
>
> =A0 - Jan

It's not the UCF file.  The fact that the buffered input is labeled
extref_clk_pin_IBUFG, with a "G" at the end shows that the pin is
indeed a global clock input and the appropriate input buffer is in
use.  If you don't run this net to either a BUFG or a DCM in the
chip, however you won't get the global routing resources you
expect.  Normally ISE will insert the correct buffers into the
design unless you change some default settings or specifically
indicate the clock buffer type in your source.  You can open
the design in FPGA editor to see what happened to this net.

Regards,
Gabor

Article: 142310
Subject: Re: Implementing VHDL code in an embedded processor design and
From: Griffin <captain.griffin@gmail.com>
Date: Mon, 3 Aug 2009 12:17:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
> > The trick here is is that I'm not sure how to implement and actually
> > use IPs with a synthesized CPU, which is what I must look into I
> > guess. Essentially, I understand the project build process until one
> > gets to the Xilinx SDK. The way I understand it, the SDK allows one to
> > apply C and C++ code to an FPGA project.
>
> Yes, SDK allows to load the C/C++ code to microblaze that is
> configured in FPGA. Now, this microblaze (or any other soft-core
> processor) is on of the hardwares that can be in FPGA. You can
> describe your own peripherals/ hardwares using languages like VHDL/
> Verilog (or other..) or use IPs designed by others. These can also be
> placed within the same FPGA.
> Now, I think which is your question: How to integrate both hardware
> and software.
> Use (assuming you want to use microblaze) Xilinx's EDK or XPS . You
> can use "The Create and Import Peripheral Wizard" in XPS to add your
> IPs into the system and make it talk with the microblaze.
>
> > Can anyone point me in the right direction for use of the SDK to
> > implement IPs such as memory interfaces and ethernet controllers (i.e.
> > a good reference document, a working example of something doing one of
> > these things, etc.)
>
> You can get some, just google with keywords like: custom peripheral
> edk; create and import peripheral wizard; ...


Thank you kindly. I think I'm headed in the right direction now.

Article: 142311
Subject: Re: ucf and clock pin placement on Spartan 3E?
From: JanW <no_spam@thanks.net>
Date: Mon, 03 Aug 2009 22:17:52 +0300
Links: << >>  << T >>  << A >>
gabor kirjoitti:
> It's not the UCF file.  The fact that the buffered input is labeled
> extref_clk_pin_IBUFG, with a "G" at the end shows that the pin is
> indeed a global clock input and the appropriate input buffer is in
> use.  

Ups, good catch.

> If you don't run this net to either a BUFG or a DCM in the
> chip, however you won't get the global routing resources you
> expect.  

It should go directly to a DCM.

Generated that dcm in XPS 10.1 with the IP Catalog -> DCM (SP) -> ip 
setup wizard. And the generated wrapper contains C_CLKIN_BUF => TRUE 
and the system.vhdl has

extref_clk_s <= extref_clk_pin;
DCM_SP_INST : dcm_sp_inst_wrapper
   port map (
       CLKIN => extref_clk_s,
       CLKFB => clk_ext_clk0,
       CLK0 => clk_ext_clk0,
       CLKFX => clk_ext,
       LOCKED => outDCMlocked_s,
       ...
   );

> Normally ISE will insert the correct buffers into the
> design unless you change some default settings or specifically
> indicate the clock buffer type in your source.  

Ok. I did change the C_CLKIN_BUF to true i think. Will retry.

> You can open
> the design in FPGA editor to see what happened to this net.

True, once this tedious "make clean; make" of XPS finishes. Then I 
try to get the hang of horrific floor planner / fpga editor ;)

  - Jan

Article: 142312
Subject: Re: Xilinx 3E design programs fine with 500E but fails with 250E
From: Brian Davis <brimdavis@aol.com>
Date: Mon, 3 Aug 2009 19:07:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
Steve wrote:
>
> > - Set the FPGA mode pins to JTAG mode, not to SPI mode, when
> >   programming over JTAG using the Impact SPI flash core.
>
> I can try this, but,
>

 If you haven't tried this mode change yet, I'd suggest
that you place it at the top of the "things to do" list.

 The recommendation to select JTAG mode during indirect
SPI programming can be found in the newer Xilinx SPI
programming application notes [Ref 1].

>
> sorta defeats having a bootable FPGA.
>

 Set it to JTAG when you connect the JTAG cable to program
the SPI flash with Impact, set it back when you are done...

 Adding a mode select jumper block hardly reduces the
functionality of a board, particularly when this mode
jumper is often needed to use the JTAG port without
experiencing the sort of problems that you are seeing.

 If you want the mode selection to be automatic, the 2mm
14 pin JTAG header pinout can be used to provide a JTAG
cable detect [Ref 2].

>
> The 500E version works fine without needing to do this.
>

 These PROM/JTAG boot conflicts can vary from part to part,
and between mask steppings of the same device.

 The earlier S3E steppings had similar BPI vs. JTAG mode
conflicts, see [Ref 3] for some examples

>
> Is the source available for these? I expect I will have to
> write my own, or bite the bullet and leave the spartan and
> go with altera.
>

 The Impact SPI core source is _not_ available [Ref 4].

 There is an example of an S3E SPI flash programmer in the
S3E starter kit examples [Ref 5], but I've never used it.

 I think there is also some sort of FlashWriter app in the
EDK, but I have no experience with that one either.

Brian

-------------

[Ref 1]  S3 SPI application notes suggesting JTAG mode jumper

XAPP974 (v1.1.3) Indirect Programming of SPI Serial Flash PROMs
with Spartan-3A FPGAs

figure 2, note 5, page 4:
"
" The jumper on the M[2] pin is an enhancement for prototyping
" and debugging, to allow changing from SPI Mode M[2:0] =3D 001
" to JTAG mode M[2:0] =3D 101.
"

Table 2, page 5:
"
" For JTAG mode for programming SPI Flash PROMS,
" set M[2:0] =3D 101
"
http://www.xilinx.com/support/documentation/application_notes/xapp974.pdf


-------------

[Ref 2] Automatic JTAG Cable Detection

  The 14 pin, 2mm Xilinx JTAG header pinout allows for the
 use of pin 13 as a cable detect.

  On the newer USB II cables, pin 13 is an open drain output
 called 'PGND' that is grounded when the cable is active:

 DS593 v1.2, page 15
 http://www.xilinx.com/support/documentation/data_sheets/ds593.pdf

  On the older Parallel IV and original Platform Cable USB
 pin 13 is a ground pin:

 DS300 v3.2
 figure 17, page 9
 http://www.xilinx.com/support/documentation/data_sheets/ds300.pdf

  So tie pin 13 to a pullup on board, and use the resulting
 logic level to select the configuration mode, either
 directly or through some logic or jumpers on the board.

  For S3E, M2 is the only pin that changes between serial
 SPI (M2=3D1) and JTAG (M2=3D0) modes, so the pin 13 pullup
 could simply be tied to the M2 line.

-------------

[Ref 3] S3E JTAG/PROM conficts & steppings

 AR #22142 - Spartan-3E Configuration - I cannot program a
 Spartan-3E FPGA via JTAG if the FPGA is in BPI Mode
 http://www.xilinx.com/support/answers/22142.htm

 2008 post listing other similar bugs:
 http://groups.google.com/group/comp.arch.fpga/msg/b06ca9faf716c347

-------------

[Ref 4] Unavailability of Impact SPI core source

XAPP974 (v1.1.3)
third paragraph, page 17
"
" The core is for iMPACT runtime use only =97 the source code
" is not available for designs.
"
http://www.xilinx.com/support/documentation/application_notes/xapp974.pdf

-------------

[Ref 5] S3E Picoblaze based SPI flash programmer
 http://www.xilinx.com/products/boards/s3estarter/files/s3esk_serial_flash.=
pdf
 http://www.xilinx.com/products/boards/s3estarter/files/s3esk_serial_flash.=
zip

Article: 142313
Subject: Re: Xilinx 3E design programs fine with 500E but fails with 250E
From: Steve <srkh28@gmail.com>
Date: Mon, 3 Aug 2009 20:32:44 -0700 (PDT)
Links: << >>  << T >>  << A >>


Hi Brian,

Thanks for the solid response. Ill try the things you suggest to see
if that resolves the problem, but I do have a few initial comments on
some of these suggestions;

> =A0The recommendation to select JTAG mode during indirect
> SPI programming can be found in the newer Xilinx SPI
> programming application notes [Ref 1].


--> Thats somewhat dissapointing, as i have an existing design in
production based on their "Designs can migrate between
the XC3S250E and XC3S500E without further consideration." statement
found on page 189 of their DS312 datasheet (who knows if its current,
or true - does it matter?)

>
>
> > sorta defeats having a bootable FPGA.
>
> =A0Set it to JTAG when you connect the JTAG cable to program
> the SPI flash with Impact, set it back when you are done...

Hard to do with 0402 components, but ill bolt it on an see what
happends.

>
> =A0Adding a mode select jumper block hardly reduces the
> functionality of a board, particularly when this mode
> jumper is often needed to use the JTAG port without
> experiencing the sort of problems that you are seeing.

I think it does. For upgrades, plugging up to the JTAG port and
downloading is a lot easier than including instructions for jumpers,
especially when the product is closed to the world. DS312, it also
states JTAG always gets priority over other methods, well, up until
now. A jumper is a bug fix for this device, for xilinx. Again, may
have to do it, but if I have to spin the board again, its just as easy
for me to put another vendor device on there.


>
> =A0If you want the mode selection to be automatic, the 2mm
> 14 pin JTAG header pinout can be used to provide a JTAG
> cable detect [Ref 2].

--> I dont wish to be tied to just xilinx programmers. Native JTAG
interface is what we are using. JTAG has too many pins as it is.
>
>
>
> > The 500E version works fine without needing to do this.
>
> =A0These PROM/JTAG boot conflicts can vary from part to part,
> and between mask steppings of the same device.

Ive noticed with xilinx, the same part varies as well - going with an
xilinx ES part is suicide. However, since it was spelt out in DS312
its ok to swap a 250E with a 500E with only code changes, I sorta
thought that meant I could swap between a 250E and a 500E with only
code changes.

steve

Article: 142314
Subject: Program Memory Space for Microblaze Processor in Spartan-3A
From: Nauman Mir <mir6@hotmail.com>
Date: Mon, 3 Aug 2009 21:29:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
I want to know how much is the program memory space for Microblaze
processor in Spartan 3A device or any similar device.

and where is this program memory actually in FPGA (considering there
is no external memory attached).
(i think Microblaze processor uses on chip Block RAM for the processor
memory it was about 64KB maximum for Spartan 3 as in Xilinx Platfrom
Studio Configuration page for Microblaze)

I couldnot find related data on website, if you know where is this
detail on the web can you also give the Link.

Best Regards

Nauman Mir

Article: 142315
Subject: Re: Program Memory Space for Microblaze Processor in Spartan-3A
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Mon, 3 Aug 2009 23:03:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 4, 7:29=A0am, Nauman Mir <m...@hotmail.com> wrote:
> I want to know how much is the program memory space for Microblaze
> processor in Spartan 3A device or any similar device.
>
> and where is this program memory actually in FPGA (considering there
> is no external memory attached).
> (i think Microblaze processor uses on chip Block RAM for the processor
> memory it was about 64KB maximum for Spartan 3 as in Xilinx Platfrom
> Studio Configuration page for Microblaze)
>
> I couldnot find related data on website, if you know where is this
> detail on the web can you also give the Link.
>
> Best Regards
>
> Nauman Mir

you can configure most of the BRAMs to be used MB on chip
look at the datasheet and calculate :)

you can only uses sizes supported by EDK, but you can use
multiply blocks

like 32KB + 8KB block would give 40KB total

Antti





Article: 142316
Subject: File I/O read in verilog
From: "DAJ" <donia.jose@gmail.com>
Date: Tue, 04 Aug 2009 03:22:57 -0500
Links: << >>  << T >>  << A >>
Hi,
   I have been asked to read 8 bits at a time from a hexadecimal input
file as an input to testbench. I found a construct $readmemh in verilog but
it says that the arrangement of file has to be in this order
23
45 
67
whereas the file structure that i have is 23 45 67 ...
Can somebody help me with this file reading using I/O?
                          




Article: 142317
Subject: Re: File I/O read in verilog
From: Jon <jon@beniston.com>
Date: Tue, 4 Aug 2009 03:34:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 4 Aug, 09:22, "DAJ" <donia.j...@gmail.com> wrote:
> Hi,
> =A0 =A0I have been asked to read 8 bits at a time from a hexadecimal inpu=
t
> file as an input to testbench. I found a construct $readmemh in verilog b=
ut
> it says that the arrangement of file has to be in this order
> 23
> 45
> 67
> whereas the file structure that i have is 23 45 67 ...
> Can somebody help me with this file reading using I/O?

If the data isn't in the format you need, write a small program that
converts it into a format suitable for $readmemh.

Alteratively, if your simulator supports Verilog2001, see here:
http://www.asic-world.com/verilog/verilog2k3.html for how to use
$fscanf.

Cheers,
Jon



Article: 142318
Subject: Re: File I/O read in verilog
From: mike <gosenatorsgo@hotmail.com>
Date: Tue, 4 Aug 2009 06:15:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 4, 4:22=A0am, "DAJ" <donia.j...@gmail.com> wrote:
> Hi,
> =A0 =A0I have been asked to read 8 bits at a time from a hexadecimal inpu=
t
> file as an input to testbench. I found a construct $readmemh in verilog b=
ut
> it says that the arrangement of file has to be in this order
> 23
> 45
> 67
> whereas the file structure that i have is 23 45 67 ...
> Can somebody help me with this file reading using I/O?


Separate lines or a space between the characters (as you have
indicated) will both work.

Article: 142319
Subject: Re: File I/O read in verilog
From: gabor <gabor@alacron.com>
Date: Tue, 4 Aug 2009 06:44:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 4, 9:15=A0am, mike <gosenator...@hotmail.com> wrote:
> On Aug 4, 4:22=A0am, "DAJ" <donia.j...@gmail.com> wrote:
>
> > Hi,
> > =A0 =A0I have been asked to read 8 bits at a time from a hexadecimal in=
put
> > file as an input to testbench. I found a construct $readmemh in verilog=
 but
> > it says that the arrangement of file has to be in this order
> > 23
> > 45
> > 67
> > whereas the file structure that i have is 23 45 67 ...
> > Can somebody help me with this file reading using I/O?
>
> Separate lines or a space between the characters (as you have
> indicated) will both work.

$readmemh requires "whitespace" between the values per the
Language Reference Manual.  Modelsim should have no problem
with the data as you have it.  HOWEVER, XST, while allowing
$readmemh for initialization of memory for synthesis, requires
the entries to be one per line.  If you are using the ISE
simulator rather than ModelSim, you might find the same
"feature" holds true.  I have not tried ISIM, so you
should give it a try before jumping through the hoops
required to reformat your file.  By the way, the Verilog
LRM also allows verilog comments and address lines in
the data files for $readmemh.  XST does not support these
constructs, either.

Regards,
Gabor

Article: 142320
Subject: AES encryption of bitstream - is my design secure?
From: Rajesh Gandhi <rgandhi4086@gmail.com>
Date: Tue, 4 Aug 2009 08:14:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello,

Is it possible that even though I use AES encrypted bitstream, another
trojan/bad bitstream that mimiked my design could be loaded into FPGA?

Regards,
Raj

Article: 142321
Subject: Re: AES encryption of bitstream - is my design secure?
From: untergangsprophet <filter001@desinformation.de>
Date: Tue, 4 Aug 2009 08:59:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
> Is it possible that even though I use AES encrypted bitstream, another
> trojan/bad bitstream that mimiked my design could be loaded into FPGA?

If your design can be mimiked AES encryption seems not necessary.

Article: 142322
Subject: Re: AES encryption of bitstream - is my design secure?
From: austin <austin@xilinx.com>
Date: Tue, 4 Aug 2009 10:54:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
Raj,

With Xilinx FPGA encryption, decryption solutions since Virtex 2, only
one bitstream is allowed to be entered in secure mode.

That bistream's key must be the one in the battery backed key memory,
or the device will not program.

Some parts allow subsequent partial reconfiguration, again they must
use the same key (encrypted), so the attacker would have to know your
key in order to do this.  If they know your key, well, you are not
secure, are you?

At any time, you may program the device again with another bitstream,
but that erases the previous (decrypted) bitstream.

While programmed with a encrypted bitstream, JTAG readback is
disabled, so you can not read the device out.

But, if you place logic in your encrypted design to perform the
internal configuration readback, and readback and output the values on
a pin (for example), then you have now created your own "back - door."

We do not protect against doing something this stupid, but we do
protect the bitstream from all other attacks if you follow a few
simple rules (like:  do not build a back door into your design).

SInce Virtex 2, we have issued challenges to university students and
researchers to test our security.  In addition to being the only
approved FPGA  by the NSA for the crypto-modernization program, we
have had no method of attack succeed to date,

Article: 142323
Subject: Re: AES encryption of bitstream - is my design secure?
From: "alan@nishioka.com" <alan@nishioka.com>
Date: Tue, 4 Aug 2009 11:19:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 4, 10:54=A0am, austin <aus...@xilinx.com> wrote:
> With Xilinx FPGA encryption, decryption solutions since Virtex 2, only
> one bitstream is allowed to be entered in secure mode.
>
> That bistream's key must be the one in the battery backed key memory,
> or the device will not program.

so if you remove the battery, can you program anything you want into
the fpga?
(this is what i thought the op was asking)

Article: 142324
Subject: Re: AES encryption of bitstream - is my design secure?
From: Rajesh Gandhi <rgandhi4086@gmail.com>
Date: Tue, 4 Aug 2009 11:49:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 4, 2:19=A0pm, "a...@nishioka.com" <a...@nishioka.com> wrote:
> On Aug 4, 10:54=A0am, austin <aus...@xilinx.com> wrote:
>
> > With Xilinx FPGA encryption, decryption solutions since Virtex 2, only
> > one bitstream is allowed to be entered in secure mode.
>
> > That bistream's key must be the one in the battery backed key memory,
> > or the device will not program.
>
> so if you remove the battery, can you program anything you want into
> the fpga?
> (this is what i thought the op was asking)

Yes, it is related to what i ask. this is one method removing the
battery, if that is not possible, shorting the battery terminals until
it is drained.



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

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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