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 159500

Article: 159500
Subject: Re: Programming Problem
From: rickman <gnuarm@gmail.com>
Date: Wed, 23 Nov 2016 22:15:02 -0500
Links: << >>  << T >>  << A >>
On 11/23/2016 6:18 PM, Tim Wescott wrote:
> On Wed, 23 Nov 2016 13:55:32 -0800, lasselangwadtchristensen wrote:
>
>> Den onsdag den 23. november 2016 kl. 20.56.00 UTC+1 skrev Tim Wescott:
>>> On Wed, 23 Nov 2016 13:51:30 -0500, rickman wrote:
>>>
>>>> I use a Lattice LFXP3C-3TN100C on a production board that has been
>>>> made for several years with quantities in the thousands.  The
>>>> HW-USBN-2A JTAG programmer typically works without complaint, both of
>>>> them.  One is a Lattice unit and the other is a Chinese knockoff.
>>>>
>>>> We are trying to finish a run of 600+ units and most have completed
>>>> testing, but we have around 60 that can not be programmed.  We get an
>>>> error that the device ID can't be verified.  The value returned is
>>>> 0xFFFFFFFE while the expected value is 0x01255043.  I would say there
>>>> is a problem with a bad trace, but then I would expect *all* F's
>>>> rather than just one bit being a zero.
>>>>
>>>> I've traced the signals and they are getting where they belong.
>>>> Signals TDI and TMS are pulled up to 3.3 volts while TCK is not and
>>>> only reaches 2.0 volts.  I can see transitions on TDI with pulses in
>>>> the microsecond range.  This is the same with working boards.
>>>>
>>>> These chips only need Vcc, PROG_N high and the four JTAG signals,
>>>> TMS, TCK, TDO and TDI to be connected in order to program them.  We
>>>> seem to have all that.
>>>>
>>>> Any ideas on what to check?  The test fixture will program a good
>>>> board just fine.  But these 60 units can't even pass chip ID
>>>> verification.  I think I'm ready to replace the FPGA on one of them.
>>>
>>> Have you looked at the TDO line while the thing is ID-ing the chip?
>>> Are you getting something that looks like 0x01255043 in there, or all
>>> ones? If you can get your hands on one good and some bad boards you
>>> should learn something.
>>>
>>> An exponentially decaying high voltage might come across as 0xfffffffe,
>>> but I would expect that it would then sometimes come across as all 'f',
>>> or sometimes as 0xfffffffc, 0xfffffff8, etc.
>>
>> or rising voltage if the data is sent LSB first
>
> Then it would be much easier to believe a reliable 0 LSB with all ones
> following.

BTW, thanks to everyone for the suggestions.  :)

-- 

Rick C

Article: 159501
Subject: Re: Phrasing!
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Fri, 25 Nov 2016 15:26:01 -0600
Links: << >>  << T >>  << A >>
On Sat, 19 Nov 2016 14:15:18 -0800, Kevin Neilson wrote:

> Here's an interesting synthesis result.  I synthesized this with Vivado
> for Virtex-7:
> 
> reg [68:0] x;
> reg x_neq_0;
> always@(posedge clk) x_neq_0 <= x!=0; // version 1
> 
> Then I rephrased the logic:
> 
> reg [68:0] x;
> reg x_neq_0;
> always@(posedge clk) x_neq_0 <= |x;   // version 2
> 
> These should be the same, right?
> 
> Version 1 uses 23 3-input LUTs on the first level followed by a 23-long
> carry chain (6 CARRY4 blocks).  This is twice as big as it should be.
> 
> Version 2 is 3 levels of LUTs, 12 6-input LUTs on the first level, 15
> total.
> 
> Neither is optimal.  What I really want is a combination, 12 6-input
> LUTs followed by 3 CARRY4s.
> 
> This is supposed to be the era of high-level synthesis...

Reading this whole thread, I'm reminded of a gripe I have about the FPGA 
manufacturers, or at least Xilinx and Altera.

If they -- or just any one of them -- would PUBLISH the details of how 
their bitfiles map to the workings of their FPGAs, then all of a sudden 
that company's stuff would be the subject of all the intensive university 
research on FPGA optimization that you might desire, and possibly even 
see an open-source tools ecology grow around its parts.

It wouldn't immediately lead to nirvana, but it may at least lead to more 
and better optimization, and lots of people experimenting with different 
optimization approaches.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

Article: 159502
Subject: Re: Phrasing!
From: rickman <gnuarm@gmail.com>
Date: Fri, 25 Nov 2016 23:57:31 -0500
Links: << >>  << T >>  << A >>
On 11/25/2016 4:26 PM, Tim Wescott wrote:
>
> Reading this whole thread, I'm reminded of a gripe I have about the FPGA
> manufacturers, or at least Xilinx and Altera.
>
> If they -- or just any one of them -- would PUBLISH the details of how
> their bitfiles map to the workings of their FPGAs, then all of a sudden
> that company's stuff would be the subject of all the intensive university
> research on FPGA optimization that you might desire, and possibly even
> see an open-source tools ecology grow around its parts.
>
> It wouldn't immediately lead to nirvana, but it may at least lead to more
> and better optimization, and lots of people experimenting with different
> optimization approaches.

Let's say I am Xilinx...  I have a bazillion dollars of investment into 
my products and the support software.  I sell to large companies who 
want reliable, consistent products.  I open up my chip design and a 
bunch of university idealists start creating tools for my devices.  The 
tools work to varying degrees and are used for a number of different 
designs by a wide variety of groups.

So what happens when some of these groups report problems "with the 
chips"?  Are these problems really with the chips or with the tools?  If 
any of these groups ask us to deal with these problems, how do we begin?

In other words, how do we keep these tools from causing problems with 
our reputation?

-- 

Rick C

Article: 159503
Subject: Re: Phrasing!
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Fri, 25 Nov 2016 23:41:21 -0600
Links: << >>  << T >>  << A >>
On Fri, 25 Nov 2016 23:57:31 -0500, rickman wrote:

> On 11/25/2016 4:26 PM, Tim Wescott wrote:
>>
>> Reading this whole thread, I'm reminded of a gripe I have about the
>> FPGA manufacturers, or at least Xilinx and Altera.
>>
>> If they -- or just any one of them -- would PUBLISH the details of how
>> their bitfiles map to the workings of their FPGAs, then all of a sudden
>> that company's stuff would be the subject of all the intensive
>> university research on FPGA optimization that you might desire, and
>> possibly even see an open-source tools ecology grow around its parts.
>>
>> It wouldn't immediately lead to nirvana, but it may at least lead to
>> more and better optimization, and lots of people experimenting with
>> different optimization approaches.
> 
> Let's say I am Xilinx...  I have a bazillion dollars of investment into
> my products and the support software.  I sell to large companies who
> want reliable, consistent products.  I open up my chip design and a
> bunch of university idealists start creating tools for my devices.  The
> tools work to varying degrees and are used for a number of different
> designs by a wide variety of groups.
> 
> So what happens when some of these groups report problems "with the
> chips"?  Are these problems really with the chips or with the tools?  If
> any of these groups ask us to deal with these problems, how do we begin?
> 
> In other words, how do we keep these tools from causing problems with
> our reputation?

"You have reached the Xilinx automated help line.  To ask about problems 
using our chips with unapproved tools, please hang up now..."

But yes, I see your point.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

Article: 159504
Subject: Re: Phrasing!
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Sat, 26 Nov 2016 09:52:32 +0000
Links: << >>  << T >>  << A >>
On 25/11/16 21:26, Tim Wescott wrote:
> On Sat, 19 Nov 2016 14:15:18 -0800, Kevin Neilson wrote:
>
>> Here's an interesting synthesis result.  I synthesized this with Vivado
>> for Virtex-7:
>>
>> reg [68:0] x;
>> reg x_neq_0;
>> always@(posedge clk) x_neq_0 <= x!=0; // version 1
>>
>> Then I rephrased the logic:
>>
>> reg [68:0] x;
>> reg x_neq_0;
>> always@(posedge clk) x_neq_0 <= |x;   // version 2
>>
>> These should be the same, right?
>>
>> Version 1 uses 23 3-input LUTs on the first level followed by a 23-long
>> carry chain (6 CARRY4 blocks).  This is twice as big as it should be.
>>
>> Version 2 is 3 levels of LUTs, 12 6-input LUTs on the first level, 15
>> total.
>>
>> Neither is optimal.  What I really want is a combination, 12 6-input
>> LUTs followed by 3 CARRY4s.
>>
>> This is supposed to be the era of high-level synthesis...
>
> Reading this whole thread, I'm reminded of a gripe I have about the FPGA
> manufacturers, or at least Xilinx and Altera.
>
> If they -- or just any one of them -- would PUBLISH the details of how
> their bitfiles map to the workings of their FPGAs, then all of a sudden
> that company's stuff would be the subject of all the intensive university
> research on FPGA optimization that you might desire, and possibly even
> see an open-source tools ecology grow around its parts.
>
> It wouldn't immediately lead to nirvana, but it may at least lead to more
> and better optimization, and lots of people experimenting with different
> optimization approaches.

Many people have suggested that advantage.

I presume the information will never be released because
the information is
- not part of an "API" that is guaranteed over time
- highly proprietary,
- highly device specific,
- possibly varies and is corrected over time (Xilinx
   is good at suite updates)
- only available in a form that is directly relevant
   to their design tools, i.e. tightly coupled)
and hence is
- difficult for someone else to interpret and process
   correctly
- opens all sorts of cans of worms if a third party
   gets it wrong

Analogy: Intel guarantee the "machine code API" of
their processors, but the detailed internal structure
is closely and varies significantly across processor
generations.

Article: 159505
Subject: Re: Phrasing!
From: Richard Damon <Richard@Damon-Family.org>
Date: Sat, 26 Nov 2016 10:38:12 -0500
Links: << >>  << T >>  << A >>
On 11/25/16 4:26 PM, Tim Wescott wrote:
> Reading this whole thread, I'm reminded of a gripe I have about the FPGA
> manufacturers, or at least Xilinx and Altera.
>
> If they -- or just any one of them -- would PUBLISH the details of how
> their bitfiles map to the workings of their FPGAs, then all of a sudden
> that company's stuff would be the subject of all the intensive university
> research on FPGA optimization that you might desire, and possibly even
> see an open-source tools ecology grow around its parts.
>
> It wouldn't immediately lead to nirvana, but it may at least lead to more
> and better optimization, and lots of people experimenting with different
> optimization approaches.
>

The big issue is that much of the information that would be included in 
such a publication is information classified by the companies has highly 
competition sensitive. While companies document quite well the basic 
structure of the fundamental Logic Elements and I/O Blocks (and other 
special computational blocks), what is normally not well described, 
except in very general terms, is the routing. In many ways the routing 
is the secret sauce that will make or break a product line. If the 
routing is too weak, users will find they can't use a lot of the logic 
in the device (what they think they are paying for), too much routing 
and the chips get slower and too expensive (since building the routing 
IS a significant part of the cost of a device).

To 'Open Source' the bitfiles, you be necessity need to explain and 
document how you configured your sparse routing matrix, which may well 
help your competitors next generation of products, at the cost of your 
future products.

Article: 159506
Subject: Re: Phrasing!
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Sat, 26 Nov 2016 10:41:16 -0800 (PST)
Links: << >>  << T >>  << A >>
> So what happens when some of these groups report problems "with the=20
> chips"?  Are these problems really with the chips or with the tools?  If=
=20
> any of these groups ask us to deal with these problems, how do we begin?
>=20
> In other words, how do we keep these tools from causing problems with=20
> our reputation?

I can totally understand why Xilinx wouldn't want to mess with this.  It's =
a support nightmare and customers would definitely associate poor open-sour=
ce software with the chips.  I'm not even convinced that open-source tools =
would be any better.

At least, in the worst case, I can instantiate primitives, but I wish the t=
ools gave me a little more ability to override bad decisions without doing =
that.  There are a lot of case in which I can do a better job but if I put =
in KEEPs, the tools ignore them, leaving me little choice but to instantiat=
e primitives.  Another thing they could do is to have more synthesis direct=
ives.  There are lots of good structures in the hardware, such as F7-F9 mux=
es, that the synthesizer almost refuses to use, and I can only make use of =
by using primitives.  Perhaps a directive would allow me to infer a mux but=
 to force (*USE_F7*).

And the built-in FIFOs:  why can't I infer them?  Preferably using the push=
/pop keywords from SystemVerilog.  That is the kind of "high-level synthesi=
s" I am looking for:  to not have to write structural HDL.  These kinds of =
incremental changes to their tools would be far more useful than their HLS =
or AccelDSP or whatever.

I wish, after working on this since 1984, they had more solid synthesis.  T=
here is supposed to be an intermediate layer between language-parsing and s=
ynthesis to primitives.  When I write the same logic in two slightly differ=
ent ways and get totally different primitives, I know that something is klu=
dged.  When I have to DeMorganize by hand to get better synthesis something=
 is wrong.  I am being paid to work out complex problems in Galois arithmet=
ic, not to do freshman-level Boolean logic.

Article: 159507
Subject: Re: Phrasing!
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 26 Nov 2016 19:40:39 +0000 (GMT)
Links: << >>  << T >>  << A >>
Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
> Analogy: Intel guarantee the "machine code API" of
> their processors, but the detailed internal structure
> is closely and varies significantly across processor
> generations.

There is indeed work going on into FPGA 'virtualisation' - creating
vendor-neutral intermediate structures that open tools can compile down to,
that either vendor tools can pick up and compile or will map to some
pre-synthesised FPGA-on-FPGA.

I'm not sure if there's anything near mainstream, but I can see it's going
to become increasingly relevant - if Microsoft have a datacentre containing
a mix of Virtex 6, Virtex 7, Ultrascale, Stratix V, Stratix 10, ...  FPGAs,
based on whatever models were cheap when they bought that batch of servers,
the number of images that needs to be supported will start multiplying and
so an 'ISA' for FPGAs would help the heterogeneity problem.

Theo

Article: 159508
Subject: Re: Programming Problem
From: Les Cargill <lcargill99@comcast.com>
Date: Sun, 27 Nov 2016 12:57:02 -0600
Links: << >>  << T >>  << A >>
rickman wrote:
> I use a Lattice LFXP3C-3TN100C on a production board that has been made
> for several years with quantities in the thousands.  The HW-USBN-2A JTAG
> programmer typically works without complaint, both of them.  One is a
> Lattice unit and the other is a Chinese knockoff.
>
> We are trying to finish a run of 600+ units and most have completed
> testing, but we have around 60 that can not be programmed.  We get an
> error that the device ID can't be verified.  The value returned is
> 0xFFFFFFFE while the expected value is 0x01255043.  I would say there is
> a problem with a bad trace, but then I would expect *all* F's rather
> than just one bit being a zero.
>


All F's indicate a level problem on the data line(s) to me. Check
termination and levels - or watch it with a very high Z scope if you
can get the triggering right.

Adding a scope Heisenbergs the circuit but that may offer inspiration
in solutions.

> I've traced the signals and they are getting where they belong.  Signals
> TDI and TMS are pulled up to 3.3 volts while TCK is not and only reaches
> 2.0 volts.  I can see transitions on TDI with pulses in the microsecond
> range.  This is the same with working boards.
>

Are these inherently 3 volt parts? If not, ithe corcuit is overterminated.

> These chips only need Vcc, PROG_N high and the four JTAG signals, TMS,
> TCK, TDO and TDI to be connected in order to program them.  We seem to
> have all that.
>
> Any ideas on what to check?  The test fixture will program a good board
> just fine.  But these 60 units can't even pass chip ID verification.  I
> think I'm ready to replace the FPGA on one of them.
>

-- 
Les Cargill



Article: 159509
Subject: Re: Programming Problem
From: rickman <gnuarm@gmail.com>
Date: Mon, 28 Nov 2016 01:27:55 -0500
Links: << >>  << T >>  << A >>
On 11/27/2016 1:57 PM, Les Cargill wrote:
> rickman wrote:
>> I use a Lattice LFXP3C-3TN100C on a production board that has been made
>> for several years with quantities in the thousands.  The HW-USBN-2A JTAG
>> programmer typically works without complaint, both of them.  One is a
>> Lattice unit and the other is a Chinese knockoff.
>>
>> We are trying to finish a run of 600+ units and most have completed
>> testing, but we have around 60 that can not be programmed.  We get an
>> error that the device ID can't be verified.  The value returned is
>> 0xFFFFFFFE while the expected value is 0x01255043.  I would say there is
>> a problem with a bad trace, but then I would expect *all* F's rather
>> than just one bit being a zero.
>>
>
>
> All F's indicate a level problem on the data line(s) to me. Check
> termination and levels - or watch it with a very high Z scope if you
> can get the triggering right.

The return data wasn't all 1s.  It was all 1s other than a single bit 
which was zero.  All ones can have multiple problems.  The output is 
one.  TCK not getting to the chip is another.

Funny thing... I did a Google search on 0xFFFFFFFE and found my own 
reply to someone else having a similar problem.  In the end he simply 
had an unknown connection issue which cleared up while fiddling with it 
all.  Seems the 0xFFFFFFFE result is a common problem when the cabling 
is not right.  In this case it was the TDI signal.


> Adding a scope Heisenbergs the circuit but that may offer inspiration
> in solutions.
>
>> I've traced the signals and they are getting where they belong.  Signals
>> TDI and TMS are pulled up to 3.3 volts while TCK is not and only reaches
>> 2.0 volts.  I can see transitions on TDI with pulses in the microsecond
>> range.  This is the same with working boards.
>>
>
> Are these inherently 3 volt parts? If not, ithe corcuit is overterminated.

Not sure what you intended to say here.  But I forgot to mention that 
another issue that confused the debug was a difference between the 
Lattice programming adapter and the Chinese device I bought a while back 
and has been working ok.  Seems the Chinese programmer only pulls the 
outputs to around 2 volts leaving no voltage margin in the worst case. 
I only see this on one signal as the others are pulled high.  TCK is 
pulled low as recommended by some reference I encountered a long time 
ago.  This prevents the single rising edge that would be detected on 
power up.  A 4.7K resistor shouldn't be a problem for any decent device, 
but obviously chip in the Chinese programmer isn't a "decent device".

So seeing the 2 volt Vhi on just one pin made me look at the test board 
to see what was holding it low.  lol


-- 

Rick C

Article: 159510
Subject: Re: Programming Problem
From: Les Cargill <lcargill99@comcast.com>
Date: Mon, 28 Nov 2016 18:32:23 -0600
Links: << >>  << T >>  << A >>
rickman wrote:
> On 11/27/2016 1:57 PM, Les Cargill wrote:
>> rickman wrote:
>>> I use a Lattice LFXP3C-3TN100C on a production board that has been made
>>> for several years with quantities in the thousands.  The HW-USBN-2A JTAG
>>> programmer typically works without complaint, both of them.  One is a
>>> Lattice unit and the other is a Chinese knockoff.
>>>
>>> We are trying to finish a run of 600+ units and most have completed
>>> testing, but we have around 60 that can not be programmed.  We get an
>>> error that the device ID can't be verified.  The value returned is
>>> 0xFFFFFFFE while the expected value is 0x01255043.  I would say there is
>>> a problem with a bad trace, but then I would expect *all* F's rather
>>> than just one bit being a zero.
>>>
>>
>>
>> All F's indicate a level problem on the data line(s) to me. Check
>> termination and levels - or watch it with a very high Z scope if you
>> can get the triggering right.
>
> The return data wasn't all 1s.  It was all 1s other than a single bit
> which was zero.  All ones can have multiple problems.  The output is
> one.  TCK not getting to the chip is another.
>

Sorry; my visual cortex returned all 1s for the 0xFFFFFFFE .... :)

> Funny thing... I did a Google search on 0xFFFFFFFE and found my own
> reply to someone else having a similar problem.  In the end he simply
> had an unknown connection issue which cleared up while fiddling with it
> all.  Seems the 0xFFFFFFFE result is a common problem when the cabling
> is not right.  In this case it was the TDI signal.
>

That's a scream.

Woohoo! Fixed.

>
>> Adding a scope Heisenbergs the circuit but that may offer inspiration
>> in solutions.
>>
>>> I've traced the signals and they are getting where they belong.  Signals
>>> TDI and TMS are pulled up to 3.3 volts while TCK is not and only reaches
>>> 2.0 volts.  I can see transitions on TDI with pulses in the microsecond
>>> range.  This is the same with working boards.
>>>
>>
>> Are these inherently 3 volt parts? If not, ithe corcuit is
>> overterminated.
>
> Not sure what you intended to say here.

R(termination) too low. Not enough current, IOW...

> But I forgot to mention that
> another issue that confused the debug was a difference between the
> Lattice programming adapter and the Chinese device I bought a while back
> and has been working ok.  Seems the Chinese programmer only pulls the
> outputs to around 2 volts leaving no voltage margin in the worst case. I
> only see this on one signal as the others are pulled high.  TCK is
> pulled low as recommended by some reference I encountered a long time
> ago.  This prevents the single rising edge that would be detected on
> power up.  A 4.7K resistor shouldn't be a problem for any decent device,
> but obviously chip in the Chinese programmer isn't a "decent device".
>

Yuck.

> So seeing the 2 volt Vhi on just one pin made me look at the test board
> to see what was holding it low.  lol
>
>

:)

--
Les Cargill

Article: 159511
Subject: Re: Programming Problem
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 29 Nov 2016 09:01:26 -0500
Links: << >>  << T >>  << A >>
rickman wrote:
> On 11/27/2016 1:57 PM, Les Cargill wrote:
>> rickman wrote:
>>> I use a Lattice LFXP3C-3TN100C on a production board that has been made
>>> for several years with quantities in the thousands.  The HW-USBN-2A JTAG
>>> programmer typically works without complaint, both of them.  One is a
>>> Lattice unit and the other is a Chinese knockoff.
>>>
>>> We are trying to finish a run of 600+ units and most have completed
>>> testing, but we have around 60 that can not be programmed.  We get an
>>> error that the device ID can't be verified.  The value returned is
>>> 0xFFFFFFFE while the expected value is 0x01255043.  I would say there is
>>> a problem with a bad trace, but then I would expect *all* F's rather
>>> than just one bit being a zero.
>>>
>>
>>
>> All F's indicate a level problem on the data line(s) to me. Check
>> termination and levels - or watch it with a very high Z scope if you
>> can get the triggering right.
> 
> The return data wasn't all 1s.  It was all 1s other than a single bit 
> which was zero.  All ones can have multiple problems.  The output is 
> one.  TCK not getting to the chip is another.
> 
> Funny thing... I did a Google search on 0xFFFFFFFE and found my own 
> reply to someone else having a similar problem.  In the end he simply 
> had an unknown connection issue which cleared up while fiddling with it 
> all.  Seems the 0xFFFFFFFE result is a common problem when the cabling 
> is not right.  In this case it was the TDI signal.
> 
> 
>> Adding a scope Heisenbergs the circuit but that may offer inspiration
>> in solutions.
>>
>>> I've traced the signals and they are getting where they belong.  Signals
>>> TDI and TMS are pulled up to 3.3 volts while TCK is not and only reaches
>>> 2.0 volts.  I can see transitions on TDI with pulses in the microsecond
>>> range.  This is the same with working boards.
>>>
>>
>> Are these inherently 3 volt parts? If not, ithe corcuit is 
>> overterminated.
> 
> Not sure what you intended to say here.  But I forgot to mention that 
> another issue that confused the debug was a difference between the 
> Lattice programming adapter and the Chinese device I bought a while back 
> and has been working ok.  Seems the Chinese programmer only pulls the 
> outputs to around 2 volts leaving no voltage margin in the worst case. I 
> only see this on one signal as the others are pulled high.  TCK is 
> pulled low as recommended by some reference I encountered a long time 
> ago.  This prevents the single rising edge that would be detected on 
> power up.  A 4.7K resistor shouldn't be a problem for any decent device, 
> but obviously chip in the Chinese programmer isn't a "decent device".
> 
> So seeing the 2 volt Vhi on just one pin made me look at the test board 
> to see what was holding it low.  lol
> 
> 

Maybe the Chinese programmer uses an open-drain output with a pull-up
to Vref rather than powering an active driver with Vref?  It would be
very strange for an active driver to limit its output to 2V with only
4.7K pulling down (426uA nominal).

-- 
Gabor

Article: 159512
Subject: Re: Programming Problem
From: rickman <gnuarm@gmail.com>
Date: Tue, 29 Nov 2016 12:55:35 -0500
Links: << >>  << T >>  << A >>
On 11/29/2016 9:01 AM, GaborSzakacs wrote:
> rickman wrote:
>> On 11/27/2016 1:57 PM, Les Cargill wrote:
>>> rickman wrote:
>>>> I use a Lattice LFXP3C-3TN100C on a production board that has been made
>>>> for several years with quantities in the thousands.  The HW-USBN-2A
>>>> JTAG
>>>> programmer typically works without complaint, both of them.  One is a
>>>> Lattice unit and the other is a Chinese knockoff.
>>>>
>>>> We are trying to finish a run of 600+ units and most have completed
>>>> testing, but we have around 60 that can not be programmed.  We get an
>>>> error that the device ID can't be verified.  The value returned is
>>>> 0xFFFFFFFE while the expected value is 0x01255043.  I would say
>>>> there is
>>>> a problem with a bad trace, but then I would expect *all* F's rather
>>>> than just one bit being a zero.
>>>>
>>>
>>>
>>> All F's indicate a level problem on the data line(s) to me. Check
>>> termination and levels - or watch it with a very high Z scope if you
>>> can get the triggering right.
>>
>> The return data wasn't all 1s.  It was all 1s other than a single bit
>> which was zero.  All ones can have multiple problems.  The output is
>> one.  TCK not getting to the chip is another.
>>
>> Funny thing... I did a Google search on 0xFFFFFFFE and found my own
>> reply to someone else having a similar problem.  In the end he simply
>> had an unknown connection issue which cleared up while fiddling with
>> it all.  Seems the 0xFFFFFFFE result is a common problem when the
>> cabling is not right.  In this case it was the TDI signal.
>>
>>
>>> Adding a scope Heisenbergs the circuit but that may offer inspiration
>>> in solutions.
>>>
>>>> I've traced the signals and they are getting where they belong.
>>>> Signals
>>>> TDI and TMS are pulled up to 3.3 volts while TCK is not and only
>>>> reaches
>>>> 2.0 volts.  I can see transitions on TDI with pulses in the microsecond
>>>> range.  This is the same with working boards.
>>>>
>>>
>>> Are these inherently 3 volt parts? If not, ithe corcuit is
>>> overterminated.
>>
>> Not sure what you intended to say here.  But I forgot to mention that
>> another issue that confused the debug was a difference between the
>> Lattice programming adapter and the Chinese device I bought a while
>> back and has been working ok.  Seems the Chinese programmer only pulls
>> the outputs to around 2 volts leaving no voltage margin in the worst
>> case. I only see this on one signal as the others are pulled high.
>> TCK is pulled low as recommended by some reference I encountered a
>> long time ago.  This prevents the single rising edge that would be
>> detected on power up.  A 4.7K resistor shouldn't be a problem for any
>> decent device, but obviously chip in the Chinese programmer isn't a
>> "decent device".
>>
>> So seeing the 2 volt Vhi on just one pin made me look at the test
>> board to see what was holding it low.  lol
>>
>>
>
> Maybe the Chinese programmer uses an open-drain output with a pull-up
> to Vref rather than powering an active driver with Vref?  It would be
> very strange for an active driver to limit its output to 2V with only
> 4.7K pulling down (426uA nominal).

I'm not sure what circuit you are imagining.  What you call Vref is Vcc 
from the unit under test, which is 3.3 volts in the case.  Also, passive 
pullup/down is very slow compared to the logic it is driving.  That is a 
great way to create noise in your circuit.

I can only assume there is something between the Vcc in and the driver, 
perhaps a protection circuit.  The 2 volts was measured with no load 
other than the voltmeter.

-- 

Rick C

Article: 159513
Subject: Re: Programming Problem
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 29 Nov 2016 14:06:13 -0500
Links: << >>  << T >>  << A >>
rickman wrote:
> On 11/29/2016 9:01 AM, GaborSzakacs wrote:
>> rickman wrote:
>>> On 11/27/2016 1:57 PM, Les Cargill wrote:
>>>> rickman wrote:
>>>>> I use a Lattice LFXP3C-3TN100C on a production board that has been 
>>>>> made
>>>>> for several years with quantities in the thousands.  The HW-USBN-2A
>>>>> JTAG
>>>>> programmer typically works without complaint, both of them.  One is a
>>>>> Lattice unit and the other is a Chinese knockoff.
>>>>>
>>>>> We are trying to finish a run of 600+ units and most have completed
>>>>> testing, but we have around 60 that can not be programmed.  We get an
>>>>> error that the device ID can't be verified.  The value returned is
>>>>> 0xFFFFFFFE while the expected value is 0x01255043.  I would say
>>>>> there is
>>>>> a problem with a bad trace, but then I would expect *all* F's rather
>>>>> than just one bit being a zero.
>>>>>
>>>>
>>>>
>>>> All F's indicate a level problem on the data line(s) to me. Check
>>>> termination and levels - or watch it with a very high Z scope if you
>>>> can get the triggering right.
>>>
>>> The return data wasn't all 1s.  It was all 1s other than a single bit
>>> which was zero.  All ones can have multiple problems.  The output is
>>> one.  TCK not getting to the chip is another.
>>>
>>> Funny thing... I did a Google search on 0xFFFFFFFE and found my own
>>> reply to someone else having a similar problem.  In the end he simply
>>> had an unknown connection issue which cleared up while fiddling with
>>> it all.  Seems the 0xFFFFFFFE result is a common problem when the
>>> cabling is not right.  In this case it was the TDI signal.
>>>
>>>
>>>> Adding a scope Heisenbergs the circuit but that may offer inspiration
>>>> in solutions.
>>>>
>>>>> I've traced the signals and they are getting where they belong.
>>>>> Signals
>>>>> TDI and TMS are pulled up to 3.3 volts while TCK is not and only
>>>>> reaches
>>>>> 2.0 volts.  I can see transitions on TDI with pulses in the 
>>>>> microsecond
>>>>> range.  This is the same with working boards.
>>>>>
>>>>
>>>> Are these inherently 3 volt parts? If not, ithe corcuit is
>>>> overterminated.
>>>
>>> Not sure what you intended to say here.  But I forgot to mention that
>>> another issue that confused the debug was a difference between the
>>> Lattice programming adapter and the Chinese device I bought a while
>>> back and has been working ok.  Seems the Chinese programmer only pulls
>>> the outputs to around 2 volts leaving no voltage margin in the worst
>>> case. I only see this on one signal as the others are pulled high.
>>> TCK is pulled low as recommended by some reference I encountered a
>>> long time ago.  This prevents the single rising edge that would be
>>> detected on power up.  A 4.7K resistor shouldn't be a problem for any
>>> decent device, but obviously chip in the Chinese programmer isn't a
>>> "decent device".
>>>
>>> So seeing the 2 volt Vhi on just one pin made me look at the test
>>> board to see what was holding it low.  lol
>>>
>>>
>>
>> Maybe the Chinese programmer uses an open-drain output with a pull-up
>> to Vref rather than powering an active driver with Vref?  It would be
>> very strange for an active driver to limit its output to 2V with only
>> 4.7K pulling down (426uA nominal).
> 
> I'm not sure what circuit you are imagining.  What you call Vref is Vcc 
> from the unit under test, which is 3.3 volts in the case.  Also, passive 
> pullup/down is very slow compared to the logic it is driving.  That is a 
> great way to create noise in your circuit.
> 
> I can only assume there is something between the Vcc in and the driver, 
> perhaps a protection circuit.  The 2 volts was measured with no load 
> other than the voltmeter.
> 

I think you imagined it right.  It wouldn't be a good way to drive TCK.
Another possibility is that they used an active drive dircuit at some
higher voltage (3.3V or more) and then connect via a simple FET-based
level shifter like the old QuickSwitch parts.  Then the active drive
would only go up to the point where the FET starts to turn off because
its source gets within Vgth of Vref.  You'd need a pullup to get the
signal beyond that point.  Your weak pulldown would fight that pullup
and limit the high drive.  In any case it seems an odd way to build
a programmer, given the easy availability of LVCMOS buffers that can
work at low voltage while taking up to 5V on their inputs.

-- 
Gabor

Article: 159514
Subject: Re: Programming Problem
From: rickman <gnuarm@gmail.com>
Date: Tue, 29 Nov 2016 14:58:19 -0500
Links: << >>  << T >>  << A >>
On 11/29/2016 2:06 PM, GaborSzakacs wrote:
> rickman wrote:
>> On 11/29/2016 9:01 AM, GaborSzakacs wrote:
>>> rickman wrote:
>>>> On 11/27/2016 1:57 PM, Les Cargill wrote:
>>>>> rickman wrote:
>>>>>> I use a Lattice LFXP3C-3TN100C on a production board that has been
>>>>>> made
>>>>>> for several years with quantities in the thousands.  The HW-USBN-2A
>>>>>> JTAG
>>>>>> programmer typically works without complaint, both of them.  One is a
>>>>>> Lattice unit and the other is a Chinese knockoff.
>>>>>>
>>>>>> We are trying to finish a run of 600+ units and most have completed
>>>>>> testing, but we have around 60 that can not be programmed.  We get an
>>>>>> error that the device ID can't be verified.  The value returned is
>>>>>> 0xFFFFFFFE while the expected value is 0x01255043.  I would say
>>>>>> there is
>>>>>> a problem with a bad trace, but then I would expect *all* F's rather
>>>>>> than just one bit being a zero.
>>>>>>
>>>>>
>>>>>
>>>>> All F's indicate a level problem on the data line(s) to me. Check
>>>>> termination and levels - or watch it with a very high Z scope if you
>>>>> can get the triggering right.
>>>>
>>>> The return data wasn't all 1s.  It was all 1s other than a single bit
>>>> which was zero.  All ones can have multiple problems.  The output is
>>>> one.  TCK not getting to the chip is another.
>>>>
>>>> Funny thing... I did a Google search on 0xFFFFFFFE and found my own
>>>> reply to someone else having a similar problem.  In the end he simply
>>>> had an unknown connection issue which cleared up while fiddling with
>>>> it all.  Seems the 0xFFFFFFFE result is a common problem when the
>>>> cabling is not right.  In this case it was the TDI signal.
>>>>
>>>>
>>>>> Adding a scope Heisenbergs the circuit but that may offer inspiration
>>>>> in solutions.
>>>>>
>>>>>> I've traced the signals and they are getting where they belong.
>>>>>> Signals
>>>>>> TDI and TMS are pulled up to 3.3 volts while TCK is not and only
>>>>>> reaches
>>>>>> 2.0 volts.  I can see transitions on TDI with pulses in the
>>>>>> microsecond
>>>>>> range.  This is the same with working boards.
>>>>>>
>>>>>
>>>>> Are these inherently 3 volt parts? If not, ithe corcuit is
>>>>> overterminated.
>>>>
>>>> Not sure what you intended to say here.  But I forgot to mention that
>>>> another issue that confused the debug was a difference between the
>>>> Lattice programming adapter and the Chinese device I bought a while
>>>> back and has been working ok.  Seems the Chinese programmer only pulls
>>>> the outputs to around 2 volts leaving no voltage margin in the worst
>>>> case. I only see this on one signal as the others are pulled high.
>>>> TCK is pulled low as recommended by some reference I encountered a
>>>> long time ago.  This prevents the single rising edge that would be
>>>> detected on power up.  A 4.7K resistor shouldn't be a problem for any
>>>> decent device, but obviously chip in the Chinese programmer isn't a
>>>> "decent device".
>>>>
>>>> So seeing the 2 volt Vhi on just one pin made me look at the test
>>>> board to see what was holding it low.  lol
>>>>
>>>>
>>>
>>> Maybe the Chinese programmer uses an open-drain output with a pull-up
>>> to Vref rather than powering an active driver with Vref?  It would be
>>> very strange for an active driver to limit its output to 2V with only
>>> 4.7K pulling down (426uA nominal).
>>
>> I'm not sure what circuit you are imagining.  What you call Vref is
>> Vcc from the unit under test, which is 3.3 volts in the case.  Also,
>> passive pullup/down is very slow compared to the logic it is driving.
>> That is a great way to create noise in your circuit.
>>
>> I can only assume there is something between the Vcc in and the
>> driver, perhaps a protection circuit.  The 2 volts was measured with
>> no load other than the voltmeter.
>>
>
> I think you imagined it right.  It wouldn't be a good way to drive TCK.
> Another possibility is that they used an active drive dircuit at some
> higher voltage (3.3V or more) and then connect via a simple FET-based
> level shifter like the old QuickSwitch parts.  Then the active drive
> would only go up to the point where the FET starts to turn off because
> its source gets within Vgth of Vref.  You'd need a pullup to get the
> signal beyond that point.  Your weak pulldown would fight that pullup
> and limit the high drive.  In any case it seems an odd way to build
> a programmer, given the easy availability of LVCMOS buffers that can
> work at low voltage while taking up to 5V on their inputs.

Once we get this batch of boards out the door, I will get both 
programmers back and do a teardown to see what they use.  I thought the 
Chinese programmer was a copy, but I've noticed it does not produce the 
same signals on the JTAG interface when failing.  I haven't tried to 
compare the signals when it works ok.

-- 

Rick C

Article: 159515
Subject: Re: Phrasing!
From: mac <acolvin@efunct.com>
Date: Tue, 29 Nov 2016 21:45:26 -0000 (UTC)
Links: << >>  << T >>  << A >>
Kevin Neilson <kevin.neilson@xilinx.com> wrote:
>> I'm not enough of an FPGA guy to make really deep comments, but this 
>> looks like the state of C compilers about 20 or so years ago.  When I 
>> started coding in C one had to write the code with an eye to the assembly 
>> that the thing was spitting out.  Now, if you've got a good optimizer 
>> (and the gnu C optimizer is better than I am on all but a very few of the 
>> processors I've worked with recently), you just express your intent and 
>> the compiler makes it happen most efficiently.
>> 
> I know!  I often feel like I'm a software guy, but stuck in the 80s,
> poring over every line generated by the assembler to make sure it's optimized.


There is an IEEE standard for synthesizable VHDL.
https://standards.ieee.org/findstds/standard/1076.6-2004.html

But is *is* like writing C per-ANSI, when every compiler had its own
variant.

-- 
mac the naf

Article: 159516
Subject: Re: Phrasing!
From: gtwrek@sonic.net (Mark Curry)
Date: Tue, 29 Nov 2016 22:19:09 -0000 (UTC)
Links: << >>  << T >>  << A >>
In article <1973855991.502148597.323655.acolvin-efunct.com@news.eternal-september.org>,
mac  <acolvin@efunct.com> wrote:
>Kevin Neilson <kevin.neilson@xilinx.com> wrote:
>>> I'm not enough of an FPGA guy to make really deep comments, but this 
>>> looks like the state of C compilers about 20 or so years ago.  When I 
>>> started coding in C one had to write the code with an eye to the assembly 
>>> that the thing was spitting out.  Now, if you've got a good optimizer 
>>> (and the gnu C optimizer is better than I am on all but a very few of the 
>>> processors I've worked with recently), you just express your intent and 
>>> the compiler makes it happen most efficiently.
>>> 
>> I know!  I often feel like I'm a software guy, but stuck in the 80s,
>> poring over every line generated by the assembler to make sure it's optimized.
>
>
>There is an IEEE standard for synthesizable VHDL.
>https://standards.ieee.org/findstds/standard/1076.6-2004.html
>
>But is *is* like writing C per-ANSI, when every compiler had its own
>variant.

There's a IEEE standard for the synthesizeable subset of Verilog-2001 too:
(IEEE 1364.1 - 2002) I know it well, as I contributed to it.  It's a shame they 
never did one for SystemVerilog.  It was suggested, but some internal politicking
on the working group struck it down.  

It's left us with a hit-and-miss method of finding the least common ground between
toolsets.  We're actively struggling with this now.

But this doesn't change Kevin's observations much.  Defining what the tool should 
accept, still gives the tool a LOT of leeway on HOW to build it - as Kevin's
shown with this example.  After all, all implementions shown in this example 
are "correct".  Some are just more optimal than others (and like always the definition
of "optimal" isn't concrete...)

Regards,

Mark



Article: 159517
Subject: SD card emulation
From: Sri G <sriakhil.gogineni@gmail.com>
Date: Wed, 30 Nov 2016 13:49:45 -0800 (PST)
Links: << >>  << T >>  << A >>
Emulating an SD card in FPGA - with =E2=80=9Cdata=E2=80=9D stored over USB =
on host PC.
=20
I=E2=80=99m testing single board computers and wearing out SD card by const=
antly flashing them with different builds, not to mention it tiring to keep=
 swapping cards in & out. So I=E2=80=99d like to emulate and SD card and =
=E2=80=9Cstore=E2=80=9D the data on a host pc connected via USB.
=20
Diagram:
=20
microSD interface <=E2=80=94 FPGA =E2=80=94> USB <=E2=80=94=E2=80=94> Host =
computer with SSD storage
=20
I will be using the SD 4-bit interface and would like to hit transfer speed=
s > 50MB/s, the clock should be ~100Mhz.
=20
Is it possible to do this with the Arty-7 kit? Or Zynq-7010? I have those r=
ight now, something more purpose specific and cheaper would be helpful to k=
now as well.

Article: 159518
Subject: Re: SD card emulation
From: rickman <gnuarm@gmail.com>
Date: Wed, 30 Nov 2016 18:05:26 -0500
Links: << >>  << T >>  << A >>
On 11/30/2016 4:49 PM, Sri G wrote:
> Emulating an SD card in FPGA - with “data” stored over USB on host PC.
>
> I’m testing single board computers and wearing out SD card by constantly flashing them with different builds, not to mention it tiring to keep swapping cards in & out. So I’d like to emulate and SD card and “store” the data on a host pc connected via USB.
>
> Diagram:
>
> microSD interface <— FPGA —> USB <——> Host computer with SSD storage
>
> I will be using the SD 4-bit interface and would like to hit transfer speeds > 50MB/s, the clock should be ~100Mhz.
>
> Is it possible to do this with the Arty-7 kit? Or Zynq-7010? I have those right now, something more purpose specific and cheaper would be helpful to know as well.

I did a little search and found a hackaday page on this by antti.lukats. 
  I have seen him around here before talking about his interesting 
projects.  The hackaday page doesn't seem to include files or even any 
detail, just a photo.  If you can get in touch with him, I expect he 
could share his HDL and maybe some of his thoughts.

Interesting project.  Is an SD card dimensions compatible with a 
standard 0.062 inch thick PCB?  I can find that the SD card is 0.083 
inches thick (2.1 mm) I believe the pins are recessed with raised 
sections between them making the contact area a different thickness.

On the other hand, SD is not really an open spec.  Can you use USB flash 
memory instead?  That should be a lot easier to interface to.

-- 

Rick C

Article: 159519
Subject: Re: SD card emulation
From: rickman <gnuarm@gmail.com>
Date: Wed, 30 Nov 2016 18:06:25 -0500
Links: << >>  << T >>  << A >>
On 11/30/2016 6:05 PM, rickman wrote:
> On 11/30/2016 4:49 PM, Sri G wrote:
>> Emulating an SD card in FPGA - with “data” stored over USB on host PC.
>>
>> I’m testing single board computers and wearing out SD card by
>> constantly flashing them with different builds, not to mention it
>> tiring to keep swapping cards in & out. So I’d like to emulate and SD
>> card and “store” the data on a host pc connected via USB.
>>
>> Diagram:
>>
>> microSD interface <— FPGA —> USB <——> Host computer with SSD storage
>>
>> I will be using the SD 4-bit interface and would like to hit transfer
>> speeds > 50MB/s, the clock should be ~100Mhz.
>>
>> Is it possible to do this with the Arty-7 kit? Or Zynq-7010? I have
>> those right now, something more purpose specific and cheaper would be
>> helpful to know as well.
>
> I did a little search and found a hackaday page on this by antti.lukats.
>  I have seen him around here before talking about his interesting
> projects.  The hackaday page doesn't seem to include files or even any
> detail, just a photo.  If you can get in touch with him, I expect he
> could share his HDL and maybe some of his thoughts.
>
> Interesting project.  Is an SD card dimensions compatible with a
> standard 0.062 inch thick PCB?  I can find that the SD card is 0.083
> inches thick (2.1 mm) I believe the pins are recessed with raised
> sections between them making the contact area a different thickness.
>
> On the other hand, SD is not really an open spec.  Can you use USB flash
> memory instead?  That should be a lot easier to interface to.

Forgot the link...

https://hackaday.io/project/6946-sd-card-emulator-lattice-xp

-- 

Rick C

Article: 159520
Subject: Re: SD card emulation
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 01 Dec 2016 02:06:09 +0000 (GMT)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
> On 11/30/2016 4:49 PM, Sri G wrote:
> > Emulating an SD card in FPGA - with “data” stored over USB on host PC.
> >
> > I’m testing single board computers and wearing out SD card by constantly
> > flashing them with different builds, not to mention it tiring to keep
> > swapping cards in & out.  So I’d like to emulate and SD card and “store”
> > the data on a host pc connected via USB.
> >
> > Is it possible to do this with the Arty-7 kit? Or Zynq-7010? I have
> > those right now, something more purpose specific and cheaper would be
> > helpful to know as well.
> 
> I did a little search and found a hackaday page on this by antti.lukats. 
>  I have seen him around here before talking about his interesting 
> projects.  The hackaday page doesn't seem to include files or even any 
> detail, just a photo.  If you can get in touch with him, I expect he 
> could share his HDL and maybe some of his thoughts.

I suspect it's just SPI mode, but you never know.

> Interesting project.  Is an SD card dimensions compatible with a 
> standard 0.062 inch thick PCB?  I can find that the SD card is 0.083 
> inches thick (2.1 mm) I believe the pins are recessed with raised 
> sections between them making the contact area a different thickness.

It's possible to make something - you may have to pad the topside of a 1.6mm
PCB with some material, or just fab a 2mm PCB.  MicroSD is 1mm which is a
common PCB thickness.

> On the other hand, SD is not really an open spec.  

It is, as long as you aren't interested in the 'Secure' part of it that
nobody uses.
https://www.sdcard.org/downloads/pls/

Emulating an SD card is doable, but tedious.  The interface is designed to
be driven at both ends by software, so there's lots of state machines you
have to implement.

Also if you want 50MB/s then that's 50MHz DDR - that might be in the part
that needs switching signalling down to 1.8v (I can't remember the cutoff).
The higher speeds are more complex to work with.

> Can you use USB flash memory instead?  That should be a lot easier to
> interface to.

Something I've scoped out but not actually built is a double-ended SD card. 
One end goes in the system under test, the other end goes in a USB SD
reader.  On the card is a microSD socket with a real card in it and some
analogue switches.  Flip the switches one way and the card is 'plugged' into
the test system, flip them the other way and it connects to the PC.  Combine
this with some GPIOs for control and some power switching and you can do
automated testing - eg flash disc image to SD card with PC, 'plug' it into
test system, boot SBC from SD and run tests, turn off SBC and 'plug' into
PC, read off results.  Rinse and repeat for every build of the software.

TI has some nice SD mux chips, for instance:
http://www.ti.com/lit/ds/symlink/ts3a27518e-q1.pdf
I can't remember the one I've used most recently, but it was in that family.

Ah, looks like somebody did it already:
http://hackaday.com/2014/06/08/the-in-circuit-sd-card-switch/

I'm sure there are easier ways to do this than SD emulation - the same idea
with USB for instance.  But some SBCs like the Raspberry Pi (until recently
at least) like booting from SD.

Theo

(I have form on evil SD interfaces - my current hackery  is a DIMM to SD
card interface...)

Article: 159521
Subject: Re: Phrasing!
From: mac <acolvin@efunct.com>
Date: Thu, 1 Dec 2016 22:54:28 -0000 (UTC)
Links: << >>  << T >>  << A >>
> But is *is* like writing C per-ANSI, when every compiler had its own variant.

pre-ANSI

The churn in language revisions isn't helping either

Article: 159522
Subject: Re: SD card emulation
From: sriakhil@disconusa.com
Date: Thu, 1 Dec 2016 23:03:51 -0800 (PST)
Links: << >>  << T >>  << A >>
I stumbled on that project but its almost 10 years old! Nevertheless, I reached out to Antti Luktas, hopefully he's not too busy to get back to me :)

Making the physical connection isn't too difficult: https://www.amazon.com/48cm-Sd-micro-Card-Extender-Cable/dp/B007WYRO7O 

Even jumper cables are suitable at 350 Mhz..

The specification for the SD protocol is nearly completely available in the Simple SD Specification freely available on sdcard.org - the state machines I'd need are bootup (3.3v), negotiating to high speed (which switches to 1.8v) and data transfer.

The SD-MUX option wears out, I've run through a couple SD cards already which is why I'm looking into the FPGA approach - not to mention faster in speed.

I'm uncertain about FPGA sizing and FPGA's in general which is why I posted here - there doesn't seem to be any relatable data between different FPGA manufacturers and I'm trying to keep costs low if I need to make a lot of boards.

Article: 159523
Subject: Re: SD card emulation
From: Sri G <sriakhil.gogineni@gmail.com>
Date: Thu, 1 Dec 2016 23:04:44 -0800 (PST)
Links: << >>  << T >>  << A >>
I stumbled on that project but its almost 10 years old! Nevertheless, I reached out to Antti Luktas, hopefully he's not too busy to get back to me :) 

Making the physical connection isn't too difficult: https://www.amazon.com/48cm-Sd-micro-Card-Extender-Cable/dp/B007WYRO7O 

Even jumper cables are suitable at 350 Mhz.. 

The specification for the SD protocol is nearly completely available in the Simple SD Specification freely available on sdcard.org - the state machines I'd need are bootup (3.3v), negotiating to high speed (which switches to 1.8v) and data transfer. 

The SD-MUX option wears out, I've run through a couple SD cards already which is why I'm looking into the FPGA approach - not to mention faster in speed. 

I'm uncertain about FPGA sizing and FPGA's in general which is why I posted here - there doesn't seem to be any relatable data between different FPGA manufacturers and I'm trying to keep costs low if I need to make a lot of boards. 

Article: 159524
Subject: Re: Phrasing!
From: o pere o <me@somewhere.net>
Date: Fri, 2 Dec 2016 09:10:15 +0100
Links: << >>  << T >>  << A >>
On 26/11/16 05:57, rickman wrote:
> On 11/25/2016 4:26 PM, Tim Wescott wrote:
>>
>> Reading this whole thread, I'm reminded of a gripe I have about the FPGA
>> manufacturers, or at least Xilinx and Altera.
>>
>> If they -- or just any one of them -- would PUBLISH the details of how
>> their bitfiles map to the workings of their FPGAs, then all of a sudden
>> that company's stuff would be the subject of all the intensive university
>> research on FPGA optimization that you might desire, and possibly even
>> see an open-source tools ecology grow around its parts.
>>
>> It wouldn't immediately lead to nirvana, but it may at least lead to more
>> and better optimization, and lots of people experimenting with different
>> optimization approaches.
>
> Let's say I am Xilinx...  I have a bazillion dollars of investment into
> my products and the support software.  I sell to large companies who
> want reliable, consistent products.  I open up my chip design and a
> bunch of university idealists start creating tools for my devices.  The
> tools work to varying degrees and are used for a number of different
> designs by a wide variety of groups.
>
> So what happens when some of these groups report problems "with the
> chips"?  Are these problems really with the chips or with the tools?  If
> any of these groups ask us to deal with these problems, how do we begin?
>
> In other words, how do we keep these tools from causing problems with
> our reputation?
>

This is a point, although a weak one. The same should also happen to the 
microcontroller industry... but does not. They are quite happy selling 
chips that are being programmed by the open-sourced gcc toolchain.

Pere



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