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 160475

Article: 160475
Subject: Re: Interface on board ADC to Spartan 3E startkit
From: Mike Perkins <spam@spam.com>
Date: Sat, 3 Feb 2018 15:18:38 +0000
Links: << >>  << T >>  << A >>
On 03/02/2018 14:30, jayanth.kalvakuntla1996@gmail.com wrote:
> Actually i want the whole code ..if you have it will you post it here it would be helpful for me

This sounds like an assignment you've been given.

Shouldn't this work be your own?


-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 160476
Subject: Re: Interface on board ADC to Spartan 3E startkit
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Sun, 4 Feb 2018 10:55:49 +0100
Links: << >>  << T >>  << A >>
On 03.02.2018 15:30, jayanth.kalvakuntla1996@gmail.com wrote:
> Actually i want the whole code ..if you have it will you post it here it would be helpful for me

Maybe you could tell us a bit more about this project of yours ?

Nicolas

Article: 160477
Subject: Re: Interface on board ADC to Spartan 3E startkit
From: Marco <invalide@nullepart.fr>
Date: Sun, 4 Feb 2018 22:12:12 +0100
Links: << >>  << T >>  << A >>
Le 03/02/2018 à 15:33, jayanth.kalvakuntla1996@gmail.com a écrit :
> Actually i want the code..if you have it will you post it here it would be helpful!
> 
Lazy!

Article: 160478
Subject: Re: Interface on board ADC to Spartan 3E startkit
From: jayanth.kalvakuntla1996@gmail.com
Date: Sun, 4 Feb 2018 19:36:58 -0800 (PST)
Links: << >>  << T >>  << A >>
We are'nt lazyy.....We have tried out all the ways of doing it but faced a lot of problems.If you have a solution,do help us.you have never seen us and trying to judge us.Dont be soo arrogant

Article: 160479
Subject: Re: Interface on board ADC to Spartan 3E startkit
From: jayanth.kalvakuntla1996@gmail.com
Date: Sun, 4 Feb 2018 19:41:20 -0800 (PST)
Links: << >>  << T >>  << A >>
Our project is to monitor industrial parameters using fpga and take possibl=
e corrective actions when these parameters go beyond their limits.So,we nee=
d to convert analog parameters to digital ones and that's the reason we nee=
d the interfacing code of adc with fpga.we tried all our ways,but could not=
 do this.

Article: 160480
Subject: Re: Interface on board ADC to Spartan 3E startkit
From: jayanth.kalvakuntla1996@gmail.com
Date: Sun, 4 Feb 2018 19:43:31 -0800 (PST)
Links: << >>  << T >>  << A >>
Our project is to monitor industrial parameters using fpga and take possibl=
e corrective actions when these parameters go beyond their limits.So,we nee=
d to convert analog parameters to digital ones and that's the reason we nee=
d the interfacing code of adc with fpga.we tried all our ways,but could not=
 do this.

Article: 160481
Subject: Re: Interface on board ADC to Spartan 3E startkit
From: =?UTF-8?Q?Adam_G=c3=b3rski?= <gorskiamalpawpkropkapeel_@xx>
Date: Mon, 5 Feb 2018 11:39:21 +0100
Links: << >>  << T >>  << A >>
On 2018-02-01 06:10, jayanth.kalvakuntla1996@gmail.com wrote:
> Hey! Even i am trying to interface adc on Spartan 3e can you help me out with the code as soon as possible!
> 

Could you be so kind and name the ADC chip ? Brand ,model etc...

Best regards

Adam Górski

Article: 160482
Subject: Re: Interface on board ADC to Spartan 3E startkit
From: Mike Perkins <spam@spam.com>
Date: Mon, 5 Feb 2018 11:37:03 +0000
Links: << >>  << T >>  << A >>
On 05/02/2018 03:43, jayanth.kalvakuntla1996@gmail.com wrote:
> Our project is to monitor industrial parameters using fpga and take
> possible corrective actions when these parameters go beyond their
> limits.So,we need to convert analog parameters to digital ones and
> that's the reason we need the interfacing code of adc with fpga.we
> tried all our ways,but could not do this.

Is this an SPI or I2C ADC?

If so there must be a number of working examples on the 'net.

Google is your friend.



-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 160483
Subject: Re: Interface on board ADC to Spartan 3E startkit
From: Mike Perkins <spam@spam.com>
Date: Mon, 5 Feb 2018 11:41:06 +0000
Links: << >>  << T >>  << A >>
On 05/02/2018 03:36, jayanth.kalvakuntla1996@gmail.com wrote:
> We are'nt lazyy.....We have tried out all the ways of doing it but
> faced a lot of problems.If you have a solution,do help us.you have
> never seen us and trying to judge us.Dont be soo arrogant

Whenever I see a post involving a rather dated starter kit and an 
element of desperation implying a deadline I think of student.

When they want the code delivered saving them any work that might look 
like 'laziness' to those who read the post.

You've said in an earlier post "We tried all our ways, but could not do 
this."

If you post the code you have written you will no longer be considered 
lazy, until then....................... I won't be holding my breath!


-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 160484
Subject: Re: Interface on board ADC to Spartan 3E startkit
From: =?UTF-8?Q?Adam_G=c3=b3rski?= <gorskiamalpawpkropkapeel_@xx>
Date: Thu, 8 Feb 2018 12:45:00 +0100
Links: << >>  << T >>  << A >>

>> Hey! Even i am trying to interface adc on Spartan 3e can you help me 
>> out with the code as soon as possible!
> Could you be so kind and name the ADC chip ? Brand ,model etc...

Obviously not.

Best regards

Adam Górski


Article: 160485
Subject: Scripts to maintain list of addresses in VHDL core communicating
From: Wojciech M. =?UTF-8?Q?Zabo=C5=82otny?= <wzab@ise.pw.edu.pl>
Date: Sun, 11 Feb 2018 14:00:31 +0000 (UTC)
Links: << >>  << T >>  << A >>
Last time I had to prepare a firmware for FPGA, that contained a complex hierarchy of blocks and subbblocks, containing registers and arrays of registers on different levels of hierarchy. Those registers were connected to simple block driven by IPbus ( https://github.com/ipbus/ipbus-firmware ) or AXI-Lite slave (e.g., generated with Tools/Create and Package New IP/Ctreate AXI4 Peripheral), that provides certain number of R/W - "Control" and RO - "Status" registers.
Until the design was small, it was easy to allocate the register addresses by hand and to connect them with manually written HDL.
However, as the design grew up, this task became more tiring and error prone.
Therefore, I have decided to prepare something to automate this task. Initially I tried to prepare my own metalanguage to describe the structure, and parse it with "pyparsing".
However, finally I have found a simpler solution, where the structure of design is described in pure Python.
Lets assume, that our design contains the top entity "Top", that contains 3 registers, N_OF_A blocks "ABlock" and, N_OF_B blocks "BBlock".
The nested blocks also have a complex structure, as shown below:

TOP
|
+-SREG: top_status
+-CREG: sys_control
+-CREG: resets
|
+-N_OF_A x ABlocks
| |
| +-SREG: A_status
| +-CREG: A_control
| +-N_OF_I2C_SLAVES x I2CBlock
| | |
| | +-CREG: I2C_Config
| | +-SREG: I2C_Status
| | +-CREG: I2C_Command
| |
| +-N_OF_SPI_SLAVES x SPIBlock
|   |
|   +-CREG: SPI_Config
|   +-SREG: SPI_Status
|   +-CREG: SPI_Tx
|   +-SREG: SPI_Rx
|
+-N_OF_B x BBlocks
  |
  +- N_OF_CELLS x CREG: Out_data
  +- N_OF_CELLS x SREG: In_data
  +- SREG: B_status
  +- CREG: B_config

Maintaining of addresses in the above structure, especially when the constants "N_OF..." are changing, is really a nightmare.
In my proposed solution, the abover structure may be described in a simple Python file:

#!/usr/bin/python3
from addr_gen import *

#Definitions of constants used in the package
c.ADDR_VERSION=int(time.time())
c.N_OF_A = 13
c.N_OF_I2C_SLAVES = 6
c.N_OF_SPI_SLAVES = 8
c.N_OF_B = 5
c.N_OF_CELLS = 12

#Define registers in the BBlock
bbl_def=aobj("BBLOCK",[
  ("out_data",sreg_def,c.N_OF_CELLS),
  ("in_data",sreg_def,c.N_OF_CELLS),
])

#Define registers in SPI block
spi_def=aobj("SPI",[
  ("spi_config",creg_def),
  ("spi_status",sreg_def),
  ("spi_tx",creg_def),
  ("spi_rx",sreg_def),
])

#Define registers in I2C block
i2c_def=aobj("I2C",[
  ("i2c_config",creg_def),
  ("i2c_status",sreg_def),
  ("i2c_command",creg_def),
])

#Define registers and subblocks in the ABlock
abl_def=aobj("ABLOCK",[
  ("a_status",creg_def),
  ("a_control",creg_def,2), #Two registers, supporting up to 64 links
  ("spi",spi_def,c.N_OF_SPI_SLAVES),
  ("i2c",spi_def,c.N_OF_I2C_SLAVES),
])

#Define registers and subblocks in the TOP block
top_def=aobj("TOP",[
  ("addr_ver",sreg_def),
  ("top_st",sreg_def),
  ("sys_ctrl",sreg_def),
  ("resets",creg_def),
  ("ab",abl_def,c.N_OF_A),
  ("bb",bbl_def,c.N_OF_B),
])

#Generate package with constants
gen_vhdl_const_package("top_const_pkg")

#Generate package with address related types and addresses
gen_vhdl_addr_package("top_adr_pkg","",crob_def,0,0)

#Generate Python module with addresses
gen_python_addr_module("top_adr",crob_def,0,0)

Running the above, generates the appropriate VHDL packages with constants and addresses, and python module with addresses.
Connection of signals in the VHDL code may be done as follows:
(I assume, that each blocks provides inputs from control registers and output to status registers in hierarchical records like below:
  type T_I2C_CTRL is record
    i2c_config : std_logic_vector(31 downto 0);
    i2c_command : std_logic_vector(31 downto 0);
  end record T_I2C_CTRL;
  type T_I2C_CTRL_ARR is array(natural range<>) of T_I2C_CTRL;

  type T_SPI_CTRL is record
    spi_config : std_logic_vector(31 downto 0);
    spi_command : std_logic_vector(31 downto 0);
  end record T_SPI_CTRL;
  type T_SPI_CTRL_ARR is array(natural range<>) of T_SPI_CTRL;

  type T_ABL_CTRL is record
    a_control: std_logic_vector(31 downto 0);
    spi : T_SPI_CTRL_ARR(0 to N_OF_SPI_SLAVES-1);
    i2c : T_I2C_CTRL_ARR(0 to N_OF_I2C_SLAVES-1);
  end record T_ABL_CTRL;
)

-- Process for connecting the signals
    process (all) is
    begin  -- process
      stat_reg(tad_addr.addr_ver) <= std_logic_vector(to_unsigned(32,ADDR_VERSION));
      stat_reg(tad_addr.top_st) <= s_top_status;
      s_top_control <= ctrl_reg(tad_addr.sys_ctrl);
      s_resets <= ctrl_reg(tad_addr.resets);
      for an in 0 to N_OF_A-1 loop
         stat_reg(tad_addr.ab(an).a_status)<=s_a_stat(an).a_status;
         s_a_ctrl(an)<=ctrl_reg(tad_addr.ab(an).a_control);
         for spin in 0 to N_OF_SPI_SLAVES loop
            s_a_ctrl(an).spi(spin).spi_config <= ctrl_reg(tad_addr.ab(an).spi(spin).spi_config;
            stat_reg(tad_addr.ab(an).spi(spin).spi_status) <= s_a_stat(an).spi(spin).spi_status;
            s_a_ctrl(an).spi(spin).spi_command <= ctrl_reg(tad_addr.ab(an).spi(spin).spi_command;
         end loop; -- spin
         -- Similar loop for I2C slaves
      end loop;  -- an
      -- Similar loop for B Blocks
    end process;

The presented approach allows to maintain addresses allocation during the long term development of the design.
I'll appreciate any improvements, suggestions and corrections.
I publish that code as Public Domain or Creative Commons CC0 license, whatever better suits your needs.
I hope that it will be useful or inspiring for somebode, but I do not provide warranty of any kind.

The described scripts are posted to alt.sources as https://groups.google.com/forum/#!topic/alt.sources/aw1SINsSHiM
I will also keep a maintained copy in https://github.com/wzab/wzab-hdl-library/tree/master/addr_gen

With best regards,
Wojtek

Article: 160486
Subject: Re: Scripts to maintain list of addresses in VHDL core communicating
From: wzab01@gmail.com
Date: Sun, 11 Feb 2018 07:48:49 -0800 (PST)
Links: << >>  << T >>  << A >>
Of course the line:
stat_reg(tad_addr.addr_ver) <= std_logic_vector(to_unsigned(32,ADDR_VERSION));
should be replaced with:
stat_reg(tad_addr.addr_ver) <= std_logic_vector(to_unsigned(ADDR_VERSION,32)); 

Article: 160487
Subject: Re: HDL simple survey - what do you actually use
From: wzab01@gmail.com
Date: Mon, 12 Feb 2018 01:08:51 -0800 (PST)
Links: << >>  << T >>  << A >>
W dniu =C5=9Broda, 10 stycznia 2018 15:17:32 UTC+1 u=C5=BCytkownik john nap=
isa=C5=82:
> I'm trying to decide on which to use for a project as the main default  t=
hat may=20
> include a number of freelance people.
>=20
> can you say which of these you actually use (the most)
> and have the best skills in
>=20
> Verilog=20
> systemVerilog
> SystemC
> VHDL
> Other
>=20
> And if possible what type of work you use it for in general
> I dont need to know why you use a particular one - and to avoid=20
> flame wars request you dont explain that.
>=20
> I'm just trying to get a general feel for what people here use regularly.
>=20
> TIA
>=20
> --=20
>=20
> john
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
> http://johntech.co.uk
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

I use mainly VHDL (I often design complex data acquisition and processing s=
ystem and havily use VHDL records to describe complex data structures)
I'm trying to use systemVerilog

BR,
Wojtek

Article: 160488
Subject: Most power efficient FPGA?
From: Peter S <psommerfeld@gmail.com>
Date: Mon, 12 Feb 2018 15:51:01 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi, I have been away from in-depth FPGA development for maybe a decade!
I am looking to design an embedded camera product where power use is key. I'd like to use an FPGA for some video manipulation not much.
I used to only use Altera FPGAs, so I know their architecture well enough. It looks like the Cyclone 10 LP is the lowest-power device they have, and their LE structure looks the same as when I last worked with Altera.
What is the most efficient Xilinx family? I don't need embedded hard CPU, transceiver I/O, or anything but DSP hard blocks and basic logic.
Using Altera's Early Power Estimator, it looks like I can get to 600 mW using 1.0 V_ccint on Cyclone 10 with about 90% of logic (15,000 LUTs and registers), block RAM (50 M9K's) and DSPs (100 9x9's).
Then I started using Xilinx's power estimator but got a bit confused because I don't know how to map the same resource usage on to a Xilinx device.
Which Xilinx parts are the most power-efficient? The Zync Ultrascale+, Zync 7000, or Artix-7?

Thanks!
Peter

Article: 160489
Subject: Re: Most power efficient FPGA?
From: Jecel <jecel@merlintec.com>
Date: Tue, 13 Feb 2018 10:56:35 -0800 (PST)
Links: << >>  << T >>  << A >>
Peter,

The ICE40 family from Lattice is, as far as I know, the FPGA with the most focus on low power. They are very small (the largest model only has 8 thousand LUTs) and don't have multipliers and stuff like that.

http://www.latticesemi.com/Products/FPGAandCPLD/iCE40

Beyond low power, there has been recently a lot of interest in these chips because they have been reversed engineered allowing a complete open source tool chain to be made compatible with them.

http://www.clifford.at/icestorm/

The devices you mentioned are not as efficient but they do allow far larger designs.

-- Jecel

Article: 160490
Subject: Re: Scripts to maintain list of addresses in VHDL core communicating
From: Benjamin Couillard <benjamin.couillard@gmail.com>
Date: Fri, 16 Feb 2018 07:14:18 -0800 (PST)
Links: << >>  << T >>  << A >>
Le dimanche 11 f=C3=A9vrier 2018 10:48:55 UTC-5, wza...@gmail.com a =C3=A9c=
rit=C2=A0:
> Of course the line:
> stat_reg(tad_addr.addr_ver) <=3D std_logic_vector(to_unsigned(32,ADDR_VER=
SION));
> should be replaced with:
> stat_reg(tad_addr.addr_ver) <=3D std_logic_vector(to_unsigned(ADDR_VERSIO=
N,32));

There is a way do it in VHDL only. Check out this thread

https://groups.google.com/d/topic/comp.lang.vhdl/0JrSaPFUJ1k/discussion

Hats off to Jonathan Bromley for this clever solution. I used it about 8 ye=
ars ago and I used Python to parse the register list to create the header f=
iles for the driver.

Article: 160491
Subject: Scripts to maintain list of addresses in VHDL core communicating with
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 16 Feb 2018 19:27:41 -0800 (PST)
Links: << >>  << T >>  << A >>
For maintenance of addresses, bus width and stuff I use a spreadsheet as th=
e code generator then simply copy/paste into the VHDL.  While not as automa=
tic as using some other language as a code generator, the bar is much lower=
 for someone else to pick up and run with starting from a spreadsheet than =
from a possibly new, foreign language.

For instantiation of the bus interface logic itself, I instantiate one inst=
ance inside a generate statement indexed by the enumeration that lists the =
components being connected for the 'write' data path. Very simple.  For the=
 'read' data path, a single component that works with an array of data to m=
ux together to produce the final readback data.

Kevin Jennings

Article: 160492
Subject: Is Zynq7000 leaky?
From: Piotr Wyderski <peter.pan@neverland.mil>
Date: Sun, 18 Feb 2018 13:35:26 +0100
Links: << >>  << T >>  << A >>
Does the Zynq7000 family contain any stored charge circuitry on
the chip? The manual says there is "On-chip boot ROM", but is
it mask-programmed or flash? If there are flash cells, then what
other SRAM-only ARM+FPGA chips should I look at?

	Best regards, Piotr

Article: 160493
Subject: Re: Is Zynq7000 leaky?
From: Richard Damon <Richard@Damon-Family.org>
Date: Sun, 18 Feb 2018 13:48:44 -0500
Links: << >>  << T >>  << A >>
On 2/18/18 7:35 AM, Piotr Wyderski wrote:
> Does the Zynq7000 family contain any stored charge circuitry on
> the chip? The manual says there is "On-chip boot ROM", but is
> it mask-programmed or flash? If there are flash cells, then what
> other SRAM-only ARM+FPGA chips should I look at?
> 
>      Best regards, Piotr

My memory of the part was that boot code mentioned is mask rom 
configured by Xilinx, which is run automatically on power on, and that 
boot loader determines the requested First Level Boot device, loads the 
program from it into the built in SRam, and executes it.

I thought I remembered that the only flash cells was a very small block 
to configure the 'Secure Boot' mode, and to store the encryption key for 
secure boot.

Article: 160494
Subject: Re: Is Zynq7000 leaky?
From: lasselangwadtchristensen@gmail.com
Date: Sun, 18 Feb 2018 11:20:31 -0800 (PST)
Links: << >>  << T >>  << A >>
Den s=C3=B8ndag den 18. februar 2018 kl. 19.48.50 UTC+1 skrev Richard Damon=
:
> On 2/18/18 7:35 AM, Piotr Wyderski wrote:
> > Does the Zynq7000 family contain any stored charge circuitry on
> > the chip? The manual says there is "On-chip boot ROM", but is
> > it mask-programmed or flash? If there are flash cells, then what
> > other SRAM-only ARM+FPGA chips should I look at?
> >=20
> >  =C2=A0=C2=A0=C2=A0=C2=A0Best regards, Piotr
>=20
> My memory of the part was that boot code mentioned is mask rom=20
> configured by Xilinx, which is run automatically on power on, and that=20
> boot loader determines the requested First Level Boot device, loads the=
=20
> program from it into the built in SRam, and executes it.
>=20
> I thought I remembered that the only flash cells was a very small block=
=20
> to configure the 'Secure Boot' mode, and to store the encryption key for=
=20
> secure boot.

that is efuses, one time programmable

Article: 160495
Subject: Re: Is Zynq7000 leaky?
From: Piotr Wyderski <peter.pan@neverland.mil>
Date: Sun, 18 Feb 2018 21:01:16 +0100
Links: << >>  << T >>  << A >>
lasselangwadtchristensen@gmail.com wrote:

>> My memory of the part was that boot code mentioned is mask rom
>> configured by Xilinx, which is run automatically on power on, and that
>> boot loader determines the requested First Level Boot device, loads the
>> program from it into the built in SRam, and executes it.
>>
>> I thought I remembered that the only flash cells was a very small block
>> to configure the 'Secure Boot' mode, and to store the encryption key for
>> secure boot.
> 
> that is efuses, one time programmable

Gents, that sounds nice, thanks. So I have a follow-up question:
is it possible to force Zynq to use single DOUT SPI configuration?
The manual says the chip supports QSPI and requires four DOUT wires,
but QSPI starts in 1x mode by default, so I am confused.

The reason is that I would like to configure the chip from
a voting memory module in order to avoid configuration stream
(and other persistent data) corruption and provide one memory
chip failure tolerance. The x4 mode would imply fourfold
replication of the voting circuitry and the bidirectional
nature of DIN doesn't help either. The old good SPI protocol
could be nicely covered by a single 74AC251 8:1 MUX.

	Best regards, Piotr

Article: 160496
Subject: Re: Is Zynq7000 leaky?
From: Richard Damon <Richard@Damon-Family.org>
Date: Sun, 18 Feb 2018 15:03:12 -0500
Links: << >>  << T >>  << A >>
On 2/18/18 2:20 PM, lasselangwadtchristensen@gmail.com wrote:
> Den søndag den 18. februar 2018 kl. 19.48.50 UTC+1 skrev Richard Damon:
>> On 2/18/18 7:35 AM, Piotr Wyderski wrote:
>>> Does the Zynq7000 family contain any stored charge circuitry on
>>> the chip? The manual says there is "On-chip boot ROM", but is
>>> it mask-programmed or flash? If there are flash cells, then what
>>> other SRAM-only ARM+FPGA chips should I look at?
>>>
>>>       Best regards, Piotr
>>
>> My memory of the part was that boot code mentioned is mask rom
>> configured by Xilinx, which is run automatically on power on, and that
>> boot loader determines the requested First Level Boot device, loads the
>> program from it into the built in SRam, and executes it.
>>
>> I thought I remembered that the only flash cells was a very small block
>> to configure the 'Secure Boot' mode, and to store the encryption key for
>> secure boot.
> 
> that is efuses, one time programmable
> 

Yes, likely efuses as not erasable. I do remember the comments about 
practicing your encription procedures using battery backed up alternate 
key storage to avoid making bricks.

Not having any flash cells would simplify the process.

Article: 160497
Subject: Re: Is Zynq7000 leaky?
From: Richard Damon <Richard@Damon-Family.org>
Date: Sun, 18 Feb 2018 15:25:26 -0500
Links: << >>  << T >>  << A >>
On 2/18/18 3:01 PM, Piotr Wyderski wrote:
> lasselangwadtchristensen@gmail.com wrote:
> 
>>> My memory of the part was that boot code mentioned is mask rom
>>> configured by Xilinx, which is run automatically on power on, and that
>>> boot loader determines the requested First Level Boot device, loads the
>>> program from it into the built in SRam, and executes it.
>>>
>>> I thought I remembered that the only flash cells was a very small block
>>> to configure the 'Secure Boot' mode, and to store the encryption key for
>>> secure boot.
>>
>> that is efuses, one time programmable
> 
> Gents, that sounds nice, thanks. So I have a follow-up question:
> is it possible to force Zynq to use single DOUT SPI configuration?
> The manual says the chip supports QSPI and requires four DOUT wires,
> but QSPI starts in 1x mode by default, so I am confused.
> 
> The reason is that I would like to configure the chip from
> a voting memory module in order to avoid configuration stream
> (and other persistent data) corruption and provide one memory
> chip failure tolerance. The x4 mode would imply fourfold
> replication of the voting circuitry and the bidirectional
> nature of DIN doesn't help either. The old good SPI protocol
> could be nicely covered by a single 74AC251 8:1 MUX.
> 
>      Best regards, Piotr

My guess you would need to put that question to Xilinx Tech Support. The 
mask programmed boot loader may (likely) not have code to handle that 
sort of case.

Article: 160498
Subject: Re: Is Zynq7000 leaky?
From: Piotr Wyderski <peter.pan@neverland.mil>
Date: Sun, 18 Feb 2018 21:42:25 +0100
Links: << >>  << T >>  << A >>
Richard Damon wrote:

> My guess you would need to put that question to Xilinx Tech Support. The 
> mask programmed boot loader may (likely) not have code to handle that 
> sort of case.

IMHO it would be enough to prevent it bumping the interface speed to x4.
Since it must start in x1 mode, the mode must certainly be supported.

	Best regards, Piotr

Article: 160499
Subject: Re: Is Zynq7000 leaky?
From: lasselangwadtchristensen@gmail.com
Date: Sun, 18 Feb 2018 13:33:56 -0800 (PST)
Links: << >>  << T >>  << A >>
Den s=C3=B8ndag den 18. februar 2018 kl. 21.01.22 UTC+1 skrev Piotr Wydersk=
i:
> lasselangwadtchristensen@gmail.com wrote:
>=20
> >> My memory of the part was that boot code mentioned is mask rom
> >> configured by Xilinx, which is run automatically on power on, and that
> >> boot loader determines the requested First Level Boot device, loads th=
e
> >> program from it into the built in SRam, and executes it.
> >>
> >> I thought I remembered that the only flash cells was a very small bloc=
k
> >> to configure the 'Secure Boot' mode, and to store the encryption key f=
or
> >> secure boot.
> >=20
> > that is efuses, one time programmable
>=20
> Gents, that sounds nice, thanks. So I have a follow-up question:
> is it possible to force Zynq to use single DOUT SPI configuration?
> The manual says the chip supports QSPI and requires four DOUT wires,
> but QSPI starts in 1x mode by default, so I am confused.
>=20
> The reason is that I would like to configure the chip from
> a voting memory module in order to avoid configuration stream
> (and other persistent data) corruption and provide one memory
> chip failure tolerance. The x4 mode would imply fourfold
> replication of the voting circuitry and the bidirectional
> nature of DIN doesn't help either. The old good SPI protocol
> could be nicely covered by a single 74AC251 8:1 MUX.
>=20
> 	Best regards, Piotr

https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-QPSI-Boo=
t-from-Legacy-1-Bit-SPI-Device/td-p/383065



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