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 157175

Article: 157175
Subject: Re: XILINX PCIe read of slow device
From: gtwrek@sonic.net (Mark Curry)
Date: Mon, 27 Oct 2014 18:36:56 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <d7e5311e-f5ea-4170-bd07-524c71da5c2b@googlegroups.com>,
David Binette  <david.binette@gmail.com> wrote:
>What is the correct way to handle a PCIE request to a slow device?
>
>I have a xilinx spartan 6 PCIe using Integrated Block for PCI Express.
>
>The BAR memory map is decoded and some addresses map to fast ram, or 
>local registers and these work OK, but some addresses map to slow 
>devices.. like I2C or internal processes that need a few cycles to 
>process before they can produce valid data to be returned to the PCI bus.
>
>Is there a way to tell the PCI bus to wait, or retry..?

David,

What specific problem are you trying to address?  

The Completion Timeout Mechanism of the PCIE spec is
optional, and must be enable by SW during device configuration.

Can you just disable this?  You can force it disable on either end
(root complex, or endpoint).  I don't think it's enabled by default,
but I can't check at the moment... 

Or are you asking something else?

Regards,

Mark


Article: 157176
Subject: Re: XILINX PCIe read of slow device
From: David Binette <david.binette@gmail.com>
Date: Mon, 27 Oct 2014 11:53:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, October 27, 2014 1:37:05 PM UTC-5, Mark Curry wrote:
> In article <d7e5311e-f5ea-4170-bd07-524c71da5c2b@googlegroups.com>,
> David Binette  wrote:
> >What is the correct way to handle a PCIE request to a slow device?
> >
> >I have a xilinx spartan 6 PCIe using Integrated Block for PCI Express.
> >
> >The BAR memory map is decoded and some addresses map to fast ram, or 
> >local registers and these work OK, but some addresses map to slow 
> >devices.. like I2C or internal processes that need a few cycles to 
> >process before they can produce valid data to be returned to the PCI bus.
> >
> >Is there a way to tell the PCI bus to wait, or retry..?
> 
> David,
> 
> What specific problem are you trying to address?  
> 
> The Completion Timeout Mechanism of the PCIE spec is
> optional, and must be enable by SW during device configuration.
> 
> Can you just disable this?  You can force it disable on either end
> (root complex, or endpoint).  I don't think it's enabled by default,
> but I can't check at the moment... 
> 
> Or are you asking something else?
> 
> Regards,
> 
> Mark

Mark, thanks, I will look into 'completion timeout mechanism' to see if it is the answer to my need. .. Am i asking something else?  I don't know, it is all kind of new to me.

part of the difficulty is that the PCI system and the local app are on different clock domains, so when the PCIE read occurs I deal with the clock crossing but it takes clock cycles before I can return something to the PCI read request


Article: 157177
Subject: Re: XILINX PCIe read of slow device
From: langwadt@fonz.dk
Date: Mon, 27 Oct 2014 16:09:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
Den mandag den 27. oktober 2014 19.05.32 UTC+1 skrev David Binette:
> What is the correct way to handle a PCIE request to a slow device?
> 
> I have a xilinx spartan 6 PCIe using Integrated Block for PCI Express.
> 
> The BAR memory map is decoded and some addresses map to fast ram, or local registers and these work OK, 
> but some addresses map to slow devices.. like I2C or internal processes that need a few cycles to process before they can produce valid data to be returned to the PCI bus.
> 
> Is there a way to tell the PCI bus to wait, or retry..?
> 
> thanks

For peripherals that a slow like I2C on a normal MCU, you would normally have 
a register to initiate the read, and a status register you can poll to see when the result is ready 


-Lasse

-Lasse

Article: 157178
Subject: looking for dev kit for ProAsic3
From: al.basili@gmail.com (alb)
Date: 28 Oct 2014 07:44:22 GMT
Links: << >>  << T >>  << A >>
Hi everyone,

I'm looking for a dev kit for a ProAsic3 A3PE3000 (microsemi) with some 
minimum amount of functional blocks around (volatile/non-volatile 
memory, few peripherals like UART, USB, SPI ...).

So far I've found this interesting piece
http://www.skylabs.si/DevBoard_PicoSky_a3pe3000.aspx

but something simpler can work as well.

The main reason is to use it as a testbed for our own processor core (an 
mblite with an extra fpu) so to have some rapid prototyping platform.

Any pointer?

Thanks,

Al

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 157179
Subject: MIPI M-PHY and FPGA?
From: "mnentwig" <24789@embeddedrelated>
Date: Tue, 28 Oct 2014 06:18:30 -0500
Links: << >>  << T >>  << A >>
Hi,

does anybody know whether it is possible (or impossible) to use an FPGA's
serial transceivers for a MIPI type 2 M-PHY link (i.e. 1.5 GBit/s)?
Xlinx' book http://www.xilinx.com/publications/archives/books/serialio.pdf
makes it look easy, but I suspect this gets very difficult once moving away
from an established standard.	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157180
Subject: Re: XILINX PCIe read of slow device
From: David Binette <david.binette@gmail.com>
Date: Tue, 28 Oct 2014 07:12:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, October 27, 2014 6:09:09 PM UTC-5, lang...@fonz.dk wrote:
> Den mandag den 27. oktober 2014 19.05.32 UTC+1 skrev David Binette:
> > What is the correct way to handle a PCIE request to a slow device?
> > 
> > I have a xilinx spartan 6 PCIe using Integrated Block for PCI Express.
> > 
> > The BAR memory map is decoded and some addresses map to fast ram, or local registers and these work OK, 
> > but some addresses map to slow devices.. like I2C or internal processes that need a few cycles to process before they can produce valid data to be returned to the PCI bus.
> > 
> > Is there a way to tell the PCI bus to wait, or retry..?
> > 
> > thanks
> 
> For peripherals that a slow like I2C on a normal MCU, you would normally have 
> a register to initiate the read, and a status register you can poll to see when the result is ready 
> 
> 
> -Lasse
> 
> -Lasse

yes, that is a good solution, but for a different problem.
In this case, the data is always 'ready' it is continuously changing, on a faster clock domain and I need a couple of cycles for the read request to cross domains.

I've tried unsuccessfully to manipulate the IP cores 'trn_tsrc_rdy_n' line to look at the read address and before setting the start of frame line in an effort to pre-fetch the data, but for some reason the core will not tolerate any delays.


Article: 157181
Subject: Re: XILINX PCIe read of slow device
From: langwadt@fonz.dk
Date: Tue, 28 Oct 2014 07:37:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
Den tirsdag den 28. oktober 2014 15.12.33 UTC+1 skrev David Binette:
> On Monday, October 27, 2014 6:09:09 PM UTC-5, lang...@fonz.dk wrote:
> > Den mandag den 27. oktober 2014 19.05.32 UTC+1 skrev David Binette:
> > > What is the correct way to handle a PCIE request to a slow device?
> > > 
> > > I have a xilinx spartan 6 PCIe using Integrated Block for PCI Express.
> > > 
> > > The BAR memory map is decoded and some addresses map to fast ram, or local registers and these work OK, 
> > > but some addresses map to slow devices.. like I2C or internal processes that need a few cycles to process before they can produce valid data to be returned to the PCI bus.
> > > 
> > > Is there a way to tell the PCI bus to wait, or retry..?
> > > 
> > > thanks
> > 
> > For peripherals that a slow like I2C on a normal MCU, you would normally have 
> > a register to initiate the read, and a status register you can poll to see when the result is ready 
> > 
> > 
> > -Lasse
> > 
> > -Lasse
> 
> yes, that is a good solution, but for a different problem.
> In this case, the data is always 'ready' it is continuously changing, on a faster clock domain and I need a couple of cycles for the read request to cross domains.
> 
> I've tried unsuccessfully to manipulate the IP cores 'trn_tsrc_rdy_n' line to look at the read address and before setting the start of frame line in an effort to pre-fetch the data, but for some reason the core will not tolerate any delays.

can't you just keep a copy of the data on the other clock domain?

-Lasse

Article: 157182
Subject: Re: XILINX PCIe read of slow device
From: David Binette <david.binette@gmail.com>
Date: Tue, 28 Oct 2014 09:25:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, October 28, 2014 9:37:43 AM UTC-5, lang...@fonz.dk wrote:
> Den tirsdag den 28. oktober 2014 15.12.33 UTC+1 skrev David Binette:
> > On Monday, October 27, 2014 6:09:09 PM UTC-5, lang...@fonz.dk wrote:
> > > Den mandag den 27. oktober 2014 19.05.32 UTC+1 skrev David Binette:
> > > > What is the correct way to handle a PCIE request to a slow device?
> > > > 
> > > > I have a xilinx spartan 6 PCIe using Integrated Block for PCI Express.
> > > > 
> > > > The BAR memory map is decoded and some addresses map to fast ram, or local registers and these work OK, 
> > > > but some addresses map to slow devices.. like I2C or internal processes that need a few cycles to process before they can produce valid data to be returned to the PCI bus.
> > > > 
> > > > Is there a way to tell the PCI bus to wait, or retry..?
> > > > 
> > > > thanks
> > > 
> > > For peripherals that a slow like I2C on a normal MCU, you would normally have 
> > > a register to initiate the read, and a status register you can poll to see when the result is ready 
> > > 
> > > 
> > > -Lasse
> > > 
> > > -Lasse
> > 
> > yes, that is a good solution, but for a different problem.
> > In this case, the data is always 'ready' it is continuously changing, on a faster clock domain and I need a couple of cycles for the read request to cross domains.
> > 
> > I've tried unsuccessfully to manipulate the IP cores 'trn_tsrc_rdy_n' line to look at the read address and before setting the start of frame line in an effort to pre-fetch the data, but for some reason the core will not tolerate any delays.
> 
> can't you just keep a copy of the data on the other clock domain?
> 
> -Lasse

yes that is feasible for a small number of items and it my be 'plan-b' if no PCI bus solution is available to me.

I like your suggestions, they are all reasonable and I'll take the best alternative I can get if I dont find a way to do this via PCIe

Article: 157183
Subject: Re: looking for dev kit for ProAsic3
From: Rob Doyle <radioengr@gmail.com>
Date: Tue, 28 Oct 2014 11:00:10 -0700
Links: << >>  << T >>  << A >>
On 10/28/2014 12:44 AM, alb wrote:
> Hi everyone,
>
> I'm looking for a dev kit for a ProAsic3 A3PE3000 (microsemi) with some
> minimum amount of functional blocks around (volatile/non-volatile
> memory, few peripherals like UART, USB, SPI ...).
>
> So far I've found this interesting piece
> http://www.skylabs.si/DevBoard_PicoSky_a3pe3000.aspx
>
> but something simpler can work as well.
>
> The main reason is to use it as a testbed for our own processor core (an
> mblite with an extra fpu) so to have some rapid prototyping platform.
>
> Any pointer?
>
> Thanks,
>
> Al
>

Why not an Igloo2?  I've pretty much dropped the ProAsic 3 from new designs.

Rob.

Article: 157184
Subject: Re: looking for dev kit for ProAsic3
From: al.basili@gmail.com (alb)
Date: 28 Oct 2014 21:43:25 GMT
Links: << >>  << T >>  << A >>
Hi Rob,
Rob Doyle <radioengr@gmail.com> wrote:
>> I'm looking for a dev kit for a ProAsic3 A3PE3000 (microsemi) with some
>> minimum amount of functional blocks around (volatile/non-volatile
>> memory, few peripherals like UART, USB, SPI ...).
[]
> Why not an Igloo2?  I've pretty much dropped the ProAsic 3 from new designs.

The Igloo2 is a very interesting device and I've used it in the past. 
Unfortunately the need for the ProAsic is strictly related to the market 
we are in: space.

There few options available when you talk about FPGA for space 
applications, essentially the RTAX family (antifuse) and the ProAsic3 
(flash based), with the latter only used in one yet to be launched 
mission (INSIGHT, Mars).

Xilinx has done efforts in this direction but I believe that Microsemi, 
former Actel, is still leading this market and will do so for a while.

So why not Igloo2? Because ESA is very picky in choosing FPGAs and 
Igloo2 is not in their target 
(http://www.google.com/url?sa=t&rct=j&q=igloo2%20space%20applications&source=web&cd=7&ved=0CEcQFjAG&url=https%3A%2F%2Famstel.estec.esa.int%2Ftecedm%2Fwebsite%2Fconferences%2Fsefuw%2Fd2_p1_ESA_Microsemi_RT_FPGA.pdf&ei=GAtQVOOuFcv7ygPhqYA4&usg=AFQjCNEaSGQdBridl53K1wtjUjvJiZ9OpA&bvm=bv.78597519,d.bGQ).

Al

Article: 157185
Subject: Re: XILINX PCIe read of slow device
From: Joe Chisolm <jchisolm6@earthlink.net>
Date: Tue, 28 Oct 2014 17:37:09 -0500
Links: << >>  << T >>  << A >>
On Mon, 27 Oct 2014 11:05:29 -0700, David Binette wrote:

> What is the correct way to handle a PCIE request to a slow device?
> 
> I have a xilinx spartan 6 PCIe using Integrated Block for PCI Express.
> 
> The BAR memory map is decoded and some addresses map to fast ram, or
> local registers and these work OK, but some addresses map to slow
> devices.. like I2C or internal processes that need a few cycles to
> process before they can produce valid data to be returned to the PCI
> bus.
> 
> Is there a way to tell the PCI bus to wait, or retry..?
> 
> thanks

This is out of UG654, page 133, for a simple PIO access.  I'm not
sure what your host driver might be using.

"While the read is being processed, the PIO design RX state machine
deasserts trn_rdst_rdy_n, causing the Receive TRN interface to stall
receiving any further TLPs until the internal Memory Read controller
completes the read access from the block RAM and generates the
completion. Deasserting trn_rst_rdy_n in this way is not required for all
designs using the core. The PIO design uses this method to simplify the
control logic of the RX state machine."

Also take a look at page 141

-- 
Chisolm
Republic of Texas

Article: 157186
Subject: Re: XILINX PCIe read of slow device
From: Sean Durkin <news_MONTH@tuxroot.de>
Date: Wed, 29 Oct 2014 09:49:06 +0100
Links: << >>  << T >>  << A >>
David Binette wrote:
> yes that is feasible for a small number of items and it my be 'plan-b' if no PCI bus solution is available to me.
> 
> I like your suggestions, they are all reasonable and I'll take the best alternative I can get if I dont find a way to do this via PCIe

I'm still not sure on what exactly your requirement is. In one post you
write that you want to read from slow devices (like I2C). That would
mean the problem is this:
- you issue a PCIe read request
- this read request triggers something, e.g. a read from an I2C device,
which takes a certain time
- meanwhile, you cannot respond to the PCIe read request in time because
you haven't received the result yet

In that case, do what Lasse suggests: Have one register to trigger the
read and another one that can be polled via PCIe indicating when the
data is ready.

But in another post you write "the data is always 'ready' it is
continuously changing, on a faster clock domain", which is something
entirely different. Is it streaming data? Do you need to catch all the
data or do you want to read out only one single value occasionally? Is
it dependant on your read, meaning that your read requests initiates a
calculation or something that you want the result of, or is the data
totally independant and you only occasionally want to read the current
value?

Since I don't understand what you really want to do, here's a few other
possibilities:

- You could just always transfer the data you have to the PCIe clock
domain whenever it changes. Each time there is a new value, always
transfer it to the PCIe clock domain immediately and put it e.g. into a
BAR register. So when you issue a PCIe read request, there's data
already there that you can put into your reply message immediately.
Worst case is you don't get the very latest value but the one before that.

- If you need to catch all the values, I'd put the data into a FIFO. You
could then e.g. issue an MSI (Message signaled interrupt) when the FIFO
is e.g. half-full (or keep polling prog_full or something) and then read
it out in a burst from the PCIe side. No need for clock-domain-crossing
for the read request, as you only read from the FIFO that has its read
port in the PCIe clock domain. No need for PCIe to wait for data too
long, since data from the FIFO is available one or two clock cycles
after the read request was issued (depending on how you configure the FIFO).

- If in your design the read request itself triggers something that
takes a while, do what Lasse suggests.

HTH,
Sean

Article: 157187
Subject: Re: XILINX PCIe read of slow device
From: David Binette <david.binette@gmail.com>
Date: Wed, 29 Oct 2014 07:13:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, October 28, 2014 5:37:12 PM UTC-5, Joe Chisolm wrote:
> On Mon, 27 Oct 2014 11:05:29 -0700, David Binette wrote:
> 
> > What is the correct way to handle a PCIE request to a slow device?
> > 
> > I have a xilinx spartan 6 PCIe using Integrated Block for PCI Express.
> > 
> > The BAR memory map is decoded and some addresses map to fast ram, or
> > local registers and these work OK, but some addresses map to slow
> > devices.. like I2C or internal processes that need a few cycles to
> > process before they can produce valid data to be returned to the PCI
> > bus.
> > 
> > Is there a way to tell the PCI bus to wait, or retry..?
> > 
> > thanks
> 
> This is out of UG654, page 133, for a simple PIO access.  I'm not
> sure what your host driver might be using.
> 
> "While the read is being processed, the PIO design RX state machine
> deasserts trn_rdst_rdy_n, causing the Receive TRN interface to stall
> receiving any further TLPs until the internal Memory Read controller
> completes the read access from the block RAM and generates the
> completion. Deasserting trn_rst_rdy_n in this way is not required for all
> designs using the core. The PIO design uses this method to simplify the
> control logic of the RX state machine."
> 
> Also take a look at page 141
> 
> -- 
> Chisolm
> Republic of Texas

I understand this
"deasserts trn_rdst_rdy_n, causing the Receive TRN interface to stall 
receiving any further TLPs"

but I'm not so much interested in "any further TLPs' as allowing the current TLP to continue processing, it seems that if i delay even a single extra cycle it causes distress to the linux host.


Article: 157188
Subject: Re: XILINX PCIe read of slow device
From: David Binette <david.binette@gmail.com>
Date: Wed, 29 Oct 2014 07:33:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, October 27, 2014 1:05:32 PM UTC-5, David Binette wrote:
> What is the correct way to handle a PCIE request to a slow device?
> 
> I have a xilinx spartan 6 PCIe using Integrated Block for PCI Express.
> 
> The BAR memory map is decoded and some addresses map to fast ram, or local registers and these work OK, 
> but some addresses map to slow devices.. like I2C or internal processes that need a few cycles to process before they can produce valid data to be returned to the PCI bus.
> 
> Is there a way to tell the PCI bus to wait, or retry..?
> 
> thanks


Hi Sean, 
Thanks for the suggestions, but I think what I really need is a way
to stall the current TLP to allow the read/access to complete.
 
 --  Is it streaming data? Do you need to catch all the 
 --  data or do you want to read out only one single value occasionally? Is 

The data is always changing, and only needs to be read occassionally.

 -- You could just always transfer the data you have to the PCIe clock 
 -- domain whenever it changes. Each time there is a new value, always 
 -- transfer it to the PCIe clock domain immediately and put it e.g. into a 
 -- BAR register. So when you issue a PCIe read request, there's data 
 -- already there that you can put into your reply message immediately. 
 -- Worst case is you don't get the very latest value but the one before that. 

That would be OK for most cases but some reads have side effects
, such as clearing another register upon read. This could be overcome
 and is not a show stopper, that part could be redesigned.
 
also since the external device has a lot of registers and they are
typically accessed by setting their address and reading the result 
(sometimes a calculated result) it would require significant changes
to create a bank of shadow values to capture them all for 
instantaneous retrieval instead of indexed on-demand access

How do other ppl handle things like doing SMBus reads over PCIe or
an I2C device.. the first read is certainly going to need some time
to complete before it can return data.

Perhaps I just fumbled something during my tests and subsequently discarded
what should have been a viable approach.

If I knew exactly how it should be done I could focus my efforts on that.


Article: 157189
Subject: Re: XILINX PCIe read of slow device
From: David Binette <david.binette@gmail.com>
Date: Wed, 29 Oct 2014 07:47:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, October 29, 2014 9:33:54 AM UTC-5, David Binette wrote:
> On Monday, October 27, 2014 1:05:32 PM UTC-5, David Binette wrote:
> > What is the correct way to handle a PCIE request to a slow device?
> > 
> > I have a xilinx spartan 6 PCIe using Integrated Block for PCI Express.
> > 
> > The BAR memory map is decoded and some addresses map to fast ram, or local registers and these work OK, 
> > but some addresses map to slow devices.. like I2C or internal processes that need a few cycles to process before they can produce valid data to be returned to the PCI bus.
> > 
> > Is there a way to tell the PCI bus to wait, or retry..?
> > 
> > thanks
> 
> 
> Hi Sean, 
> Thanks for the suggestions, but I think what I really need is a way
> to stall the current TLP to allow the read/access to complete.
>  
>  --  Is it streaming data? Do you need to catch all the 
>  --  data or do you want to read out only one single value occasionally? Is 
> 
> The data is always changing, and only needs to be read occassionally.
> 
>  -- You could just always transfer the data you have to the PCIe clock 
>  -- domain whenever it changes. Each time there is a new value, always 
>  -- transfer it to the PCIe clock domain immediately and put it e.g. into a 
>  -- BAR register. So when you issue a PCIe read request, there's data 
>  -- already there that you can put into your reply message immediately. 
>  -- Worst case is you don't get the very latest value but the one before that. 
> 
> That would be OK for most cases but some reads have side effects
> , such as clearing another register upon read. This could be overcome
>  and is not a show stopper, that part could be redesigned.
>  
> also since the external device has a lot of registers and they are
> typically accessed by setting their address and reading the result 
> (sometimes a calculated result) it would require significant changes
> to create a bank of shadow values to capture them all for 
> instantaneous retrieval instead of indexed on-demand access
> 
> How do other ppl handle things like doing SMBus reads over PCIe or
> an I2C device.. the first read is certainly going to need some time
> to complete before it can return data.
> 
> Perhaps I just fumbled something during my tests and subsequently discarded
> what should have been a viable approach.
> 
> If I knew exactly how it should be done I could focus my efforts on that.

ps, i know that SMBus is an independant bus on the PCIe connector, I don't mean to complicate the topic with that.   It was an example to illustrate only.

Article: 157190
Subject: The EDIF variant used by fit150X.exe
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Wed, 29 Oct 2014 16:12:55 +0100
Links: << >>  << T >>  << A >>
Can anyone point me to samples of the edif variant accepted by 
the atmel PLD fitters? Google can't seem to find any, and their 
free CUPL seems to generate .PLA things only.


Article: 157191
Subject: Re: The EDIF variant used by fit150X.exe
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Wed, 29 Oct 2014 17:06:41 +0100
Links: << >>  << T >>  << A >>
On 10/29/2014 04:12 PM, Johann Klammer wrote:
> Can anyone point me to samples of the edif variant accepted by 
> the atmel PLD fitters? Google can't seem to find any, and their 
> free CUPL seems to generate .PLA things only.
> 
Nevermind, I've found something...


Article: 157192
Subject: Re: XILINX PCIe read of slow device
From: Chris Higgs <chiggs.99@gmail.com>
Date: Wed, 29 Oct 2014 09:34:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, October 29, 2014 2:33:54 PM UTC, David Binette wrote:

> That would be OK for most cases but some reads have side effects
> , such as clearing another register upon read. This could be overcome
>  and is not a show stopper, that part could be redesigned.

It's generally best to avoid side-effects if at all possible and make all r=
eads idempotent.  Life is much easier for software that way.

For example, TLPs may be re-ordered, accesses above a certain size may not =
occur in the order you expect, the root complex may attempt to pre-fetch a =
value, in future you may be using this device over a lossy medium like Ethe=
rnet.

All of these things can be controlled (or worked around) in software but of=
ten lead to inefficiencies.  If you have the choice, it's always better to =
design your interface with a view to simplifying the software interaction. =
 This generally also yields simpler hardware and fewer gotchas in the docum=
entation so everyone's a winner!

Thanks,

Chris

Article: 157193
Subject: Re: XILINX PCIe read of slow device
From: gtwrek@sonic.net (Mark Curry)
Date: Wed, 29 Oct 2014 18:35:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <b22fff2a-6bf2-4285-8632-7cda5fa59541@googlegroups.com>,
David Binette  <david.binette@gmail.com> wrote:
>On Monday, October 27, 2014 1:05:32 PM UTC-5, David Binette wrote:
>> What is the correct way to handle a PCIE request to a slow device?
>> 
>> I have a xilinx spartan 6 PCIe using Integrated Block for PCI Express.
>> 
>> The BAR memory map is decoded and some addresses map to fast ram, or local registers and these work OK, 
>> but some addresses map to slow devices.. like I2C or internal processes that need a few cycles to process before they can produce valid data to be returned to the PCI bus.
>> 
>> Is there a way to tell the PCI bus to wait, or retry..?
>> 
>> thanks
>
>
>
>How do other ppl handle things like doing SMBus reads over PCIe or
>an I2C device.. the first read is certainly going to need some time
>to complete before it can return data.
>
>Perhaps I just fumbled something during my tests and subsequently discarded
>what should have been a viable approach.
>

David,

I can't offer any specific advise - but generally all PCIE transcations
are "stalled", whether they're reading from a slow device on another clock
or a "fast" device on the same clock.

For A PIO read you get:
 1.  The host issues a PIO read.  
 2.  A TLP MRd packet is formed and sent across the serial interface. 
 3.  The xilinx endpoint decodes the packet, determines that the packet
     is meant for the user logic - you.  It sends the information
     out to the user interface logic.
 4.  Your logic issues the read, and responds.
 5.  The CPLd packet is formatted and transmitted back across the PCIE
     link.
 ...

All of that takes quite a bit of time.   The fact that step 4 takes 
a few cycles (give or take 10s or perhaps even 100s) is almost irrelavant.
The PCIE time mechanism doesn't come into play until this number is
very high (I've not used it, but I'd think we're talking 10s of ms) 

The whole process has quite a bit of latency.  A few cycles 
here or there aren't going to matter. 

I don't use that specific PCIE core, nor Xilinx logic (I'm using the Virtex7 core,
with AXIS interfaces tied to my logic).  But the general flow should be the
same.  I'd review the interfaces specification to fully understand
what's required.  Are you running sims with the Xilinx logic?

Regards,

Mark



Article: 157194
Subject: Re: looking for dev kit for ProAsic3
From: rickman <gnuarm@gmail.com>
Date: Wed, 29 Oct 2014 20:09:45 -0400
Links: << >>  << T >>  << A >>
On 10/28/2014 5:43 PM, alb wrote:
> Hi Rob,
> Rob Doyle <radioengr@gmail.com> wrote:
>>> I'm looking for a dev kit for a ProAsic3 A3PE3000 (microsemi) with some
>>> minimum amount of functional blocks around (volatile/non-volatile
>>> memory, few peripherals like UART, USB, SPI ...).
> []
>> Why not an Igloo2?  I've pretty much dropped the ProAsic 3 from new designs.
>
> The Igloo2 is a very interesting device and I've used it in the past.
> Unfortunately the need for the ProAsic is strictly related to the market
> we are in: space.
>
> There few options available when you talk about FPGA for space
> applications, essentially the RTAX family (antifuse) and the ProAsic3
> (flash based), with the latter only used in one yet to be launched
> mission (INSIGHT, Mars).
>
> Xilinx has done efforts in this direction but I believe that Microsemi,
> former Actel, is still leading this market and will do so for a while.
>
> So why not Igloo2? Because ESA is very picky in choosing FPGAs and
> Igloo2 is not in their target
> (http://www.google.com/url?sa=t&rct=j&q=igloo2%20space%20applications&source=web&cd=7&ved=0CEcQFjAG&url=https%3A%2F%2Famstel.estec.esa.int%2Ftecedm%2Fwebsite%2Fconferences%2Fsefuw%2Fd2_p1_ESA_Microsemi_RT_FPGA.pdf&ei=GAtQVOOuFcv7ygPhqYA4&usg=AFQjCNEaSGQdBridl53K1wtjUjvJiZ9OpA&bvm=bv.78597519,d.bGQ).

I was supposed to work with Rich Katz at NASA once to do some testing on 
Xilinx parts for radiation susceptibility.  He tends to drag his feet 
then needs it all at once and I got busy on my end.  So it moved on 
without me.  You might try contacting him to see what they ended up 
doing with the parts.  I think the philosophy was to run the part for a 
while, then reconfigure it in case it had taken any soft errors.  I 
didn't really get how that would help, but I guess they had ways of 
using an FPGA like that.

-- 

Rick

Article: 157195
Subject: Re: looking for dev kit for ProAsic3
From: al.basili@gmail.com (alb)
Date: 30 Oct 2014 08:08:21 GMT
Links: << >>  << T >>  << A >>
Hi Rick,

rickman <gnuarm@gmail.com> wrote:
[]
> I was supposed to work with Rich Katz at NASA once to do some testing on 
> Xilinx parts for radiation susceptibility.  He tends to drag his feet 
> then needs it all at once and I got busy on my end.  So it moved on 
> without me.  You might try contacting him to see what they ended up 
> doing with the parts.  

There's a lot of documentation on klabs.org but it starts to be a little 
out dated. I'd love to work with them but our business is not interested 
in FPGA testing, with rather use the ones which have been already tested 
;-)

> I think the philosophy was to run the part for a 
> while, then reconfigure it in case it had taken any soft errors.  I 
> didn't really get how that would help, but I guess they had ways of 
> using an FPGA like that.

Xilinx has always thrived to provide a way to perform partial 
reconfiguration, so with the appropriate control logic you could sense 
where the problem is and reprogram it.

The 'Curiosity' mission hosted Xilinx parts (Rad Tolerant) but 
reprogrammability is needed to correct faults in the configuration 
registers.

Currently, at least in Europe, the trend seems to push towards flash 
based products which provide higher tolerance to radiation and 
reprogrammability.

The great benefit of reprogrammability may be its biggest weakness as 
well, though. While the possibility to reprogram the target even in 
later stages of the project (if not after the launch!) may have two 
important consequences:

1. not enough verification/validation (since there's always a chance to 
'fix it later')

2. features creeping

Current FPGA plans, as mandated by ESA, are well aware of this risk and 
boards continue to be very strict during reviews. Yet everybody is aware 
that if a bug *can* be fixed later *won't* be fixed now :-)

Al

Article: 157196
Subject: Re: looking for dev kit for ProAsic3
From: HT-Lab <hans64@htminuslab.com>
Date: Thu, 30 Oct 2014 08:27:32 +0000
Links: << >>  << T >>  << A >>
On 30/10/2014 00:09, rickman wrote:
> On 10/28/2014 5:43 PM, alb wrote:
..
>>
>> So why not Igloo2? Because ESA is very picky in choosing FPGAs and
>> Igloo2 is not in their target
>> (http://www.google.com/url?sa=t&rct=j&q=igloo2%20space%20applications&source=web&cd=7&ved=0CEcQFjAG&url=https%3A%2F%2Famstel.estec.esa.int%2Ftecedm%2Fwebsite%2Fconferences%2Fsefuw%2Fd2_p1_ESA_Microsemi_RT_FPGA.pdf&ei=GAtQVOOuFcv7ygPhqYA4&usg=AFQjCNEaSGQdBridl53K1wtjUjvJiZ9OpA&bvm=bv.78597519,d.bGQ).
>>
>
> I was supposed to work with Rich Katz at NASA once to do some testing on
> Xilinx parts for radiation susceptibility.

Xilinx has done quite some extensive radiation testing already many 
years ago (Qpro series) and they are fully qualified to be used in space 
(like the Mars Rover!)

> He tends to drag his feet

That's because he is the number 1 FPGA/Space guy in the world and tends 
to multi-task between many projects. I thought I knew a bit about FPGA's 
in space until I met him....

I would definitely contact him as he is great guy and will help you even 
when he is overloaded with other projects.

Regards,
Hans
www.ht-lab.com


> then needs it all at once and I got busy on my end.  So it moved on
> without me.  You might try contacting him to see what they ended up
> doing with the parts.  I think the philosophy was to run the part for a
> while, then reconfigure it in case it had taken any soft errors.  I
> didn't really get how that would help, but I guess they had ways of
> using an FPGA like that



Article: 157197
Subject: Re: XILINX PCIe read of slow device
From: David Binette <david.binette@gmail.com>
Date: Thu, 30 Oct 2014 05:38:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, October 27, 2014 1:05:32 PM UTC-5, David Binette wrote:
> What is the correct way to handle a PCIE request to a slow device?
> 
> I have a xilinx spartan 6 PCIe using Integrated Block for PCI Express.
> 
> The BAR memory map is decoded and some addresses map to fast ram, or local registers and these work OK, 
> but some addresses map to slow devices.. like I2C or internal processes that need a few cycles to process before they can produce valid data to be returned to the PCI bus.
> 
> Is there a way to tell the PCI bus to wait, or retry..?
> 
> thanks

Thanks Mark
for your time and comments, which were helpful.

I haven't put it on the simulator, just doing compiles and tests but the turn time is long.

Article: 157198
Subject: Re: looking for dev kit for ProAsic3
From: rickman <gnuarm@gmail.com>
Date: Thu, 30 Oct 2014 15:14:07 -0400
Links: << >>  << T >>  << A >>
On 10/30/2014 4:08 AM, alb wrote:
> Hi Rick,
>
> rickman <gnuarm@gmail.com> wrote:
> []
>> I was supposed to work with Rich Katz at NASA once to do some testing on
>> Xilinx parts for radiation susceptibility.  He tends to drag his feet
>> then needs it all at once and I got busy on my end.  So it moved on
>> without me.  You might try contacting him to see what they ended up
>> doing with the parts.
>
> There's a lot of documentation on klabs.org but it starts to be a little
> out dated. I'd love to work with them but our business is not interested
> in FPGA testing, with rather use the ones which have been already tested
> ;-)

That's why I said to get in touch with Rich Katz.  He will have some 
info on what is what in that department.


>> I think the philosophy was to run the part for a
>> while, then reconfigure it in case it had taken any soft errors.  I
>> didn't really get how that would help, but I guess they had ways of
>> using an FPGA like that.
>
> Xilinx has always thrived to provide a way to perform partial
> reconfiguration, so with the appropriate control logic you could sense
> where the problem is and reprogram it.

This was not partial configuration.  I can't say I really got the 
concept.  I mean what is happening while the device is being configured? 
  Who is running the store?


> The 'Curiosity' mission hosted Xilinx parts (Rad Tolerant) but
> reprogrammability is needed to correct faults in the configuration
> registers.
>
> Currently, at least in Europe, the trend seems to push towards flash
> based products which provide higher tolerance to radiation and
> reprogrammability.
>
> The great benefit of reprogrammability may be its biggest weakness as
> well, though. While the possibility to reprogram the target even in
> later stages of the project (if not after the launch!) may have two
> important consequences:
>
> 1. not enough verification/validation (since there's always a chance to
> 'fix it later')

Red herring.  That is an issue of your design process, not the 
technology used.


> 2. features creeping
>
> Current FPGA plans, as mandated by ESA, are well aware of this risk and
> boards continue to be very strict during reviews. Yet everybody is aware
> that if a bug *can* be fixed later *won't* be fixed now :-)

Bug fix is not feature creep.  But the point is valid.  Again it is an 
issue of the design process really.  No changes unless they can be 
adequately verified.

-- 

Rick

Article: 157199
Subject: Re: looking for dev kit for ProAsic3
From: rickman <gnuarm@gmail.com>
Date: Thu, 30 Oct 2014 15:16:04 -0400
Links: << >>  << T >>  << A >>
On 10/30/2014 4:27 AM, HT-Lab wrote:
> On 30/10/2014 00:09, rickman wrote:
>> On 10/28/2014 5:43 PM, alb wrote:
> ..
>>>
>>> So why not Igloo2? Because ESA is very picky in choosing FPGAs and
>>> Igloo2 is not in their target
>>> (http://www.google.com/url?sa=t&rct=j&q=igloo2%20space%20applications&source=web&cd=7&ved=0CEcQFjAG&url=https%3A%2F%2Famstel.estec.esa.int%2Ftecedm%2Fwebsite%2Fconferences%2Fsefuw%2Fd2_p1_ESA_Microsemi_RT_FPGA.pdf&ei=GAtQVOOuFcv7ygPhqYA4&usg=AFQjCNEaSGQdBridl53K1wtjUjvJiZ9OpA&bvm=bv.78597519,d.bGQ).
>>>
>>>
>>
>> I was supposed to work with Rich Katz at NASA once to do some testing on
>> Xilinx parts for radiation susceptibility.
>
> Xilinx has done quite some extensive radiation testing already many
> years ago (Qpro series) and they are fully qualified to be used in space
> (like the Mars Rover!)
>
>> He tends to drag his feet
>
> That's because he is the number 1 FPGA/Space guy in the world and tends
> to multi-task between many projects. I thought I knew a bit about FPGA's
> in space until I met him....
>
> I would definitely contact him as he is great guy and will help you even
> when he is overloaded with other projects.

I will second that.  I was scrambling for work back then and couldn't 
accommodate his schedule.  Now things are more relaxed for me and I 
would work with him any day.  He is a great guy.

-- 

Rick



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