EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

EDK : FSL macros defined by Xilinx are wrong

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - EDK : FSL macros defined by Xilinx are wrong

Goto page Previous  1, 2, 3 ... 362, 363, 364


Guest

Fri Nov 08, 2019 9:51 pm   



On Friday, November 8, 2019 at 1:09:04 PM UTC-6, John Larkin wrote:
Quote:
We're planning a new universal boot loader for a family of ST
processors. The uP would host the loader in a bit of local flash and
read an outboard serial flash to get the specific application code and
one or more FPGA configurations.

So, how many config bits might there be for a modern mid-range FPGA
doing a moderately complex application?

I think we could enable compression too.

Please consider this a PHB type question. I don't do FPGA development
myself, past whiteboarding.

--

John Larkin Highland Technology, Inc
picosecond timing precision measurement

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com


There's a general trend of about 60-80 bits per LUT input (can go higher).
4LUT has ~4-6 inputs, 6LUT or ALM 6-8 inputs. Count the number of LUTs in the part and multiply. Some go as high as 400M+ configuration bits.

Jim Brakefield

Stef
Guest

Sat Nov 09, 2019 12:45 am   



On 2019-11-08 Rick C wrote in comp.arch.fpga:
Quote:
On Friday, November 8, 2019 at 2:09:04 PM UTC-5, John Larkin wrote:

Please consider this a PHB type question. I don't do FPGA development
myself, past whiteboarding.

Anyone know what a "PHB type question" is?


https://dilbert.com/search_results?terms=phb

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

Corry's Law:
Paper is always strongest at the perforations.

Rick C
Guest

Sat Nov 09, 2019 12:45 am   



On Friday, November 8, 2019 at 5:48:04 PM UTC-5, Stef wrote:
Quote:
On 2019-11-08 Rick C wrote in comp.arch.fpga:
On Friday, November 8, 2019 at 2:09:04 PM UTC-5, John Larkin wrote:

Please consider this a PHB type question. I don't do FPGA development
myself, past whiteboarding.

Anyone know what a "PHB type question" is?

https://dilbert.com/search_results?terms=phb


Yeah, someone explained in the other group. A bit obscure, methinks.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

David Brown
Guest

Mon Nov 11, 2019 9:45 am   



On 09/11/2019 00:12, Rick C wrote:
Quote:
On Friday, November 8, 2019 at 5:48:04 PM UTC-5, Stef wrote:
On 2019-11-08 Rick C wrote in comp.arch.fpga:
On Friday, November 8, 2019 at 2:09:04 PM UTC-5, John Larkin wrote:

Please consider this a PHB type question. I don't do FPGA development
myself, past whiteboarding.

Anyone know what a "PHB type question" is?

https://dilbert.com/search_results?terms=phb

Yeah, someone explained in the other group. A bit obscure, methinks.


Nah. I get suspicious of any engineer who doesn't know the term PHB!

It's like not understanding the term SEP.

gtwrek
Guest

Mon Nov 11, 2019 5:45 pm   



In article <qqb5mf$e1f$1_at_dont-email.me>,
David Brown <david.brown_at_hesbynett.no> wrote:
Quote:
On 09/11/2019 00:12, Rick C wrote:
On Friday, November 8, 2019 at 5:48:04 PM UTC-5, Stef wrote:
On 2019-11-08 Rick C wrote in comp.arch.fpga:
On Friday, November 8, 2019 at 2:09:04 PM UTC-5, John Larkin wrote:

Please consider this a PHB type question. I don't do FPGA development
myself, past whiteboarding.

Anyone know what a "PHB type question" is?

https://dilbert.com/search_results?terms=phb

Yeah, someone explained in the other group. A bit obscure, methinks.


Nah. I get suspicious of any engineer who doesn't know the term PHB!

It's like not understanding the term SEP.


I had to think a bit to come up with PHB, but I got it. I've no idea
what SEP is.

But then I'm acronymn dumb (and too lazy to try and google it right
now.)

(I've got a feeling a "whoosh" at my expense is incoming...)

--Mark

David Brown
Guest

Mon Nov 11, 2019 6:45 pm   



On 11/11/2019 18:10, David Brown wrote:
Quote:
On 11/11/2019 17:33, gtwrek wrote:
In article <qqb5mf$e1f$1_at_dont-email.me>,
David Brown  <david.brown_at_hesbynett.no> wrote:
On 09/11/2019 00:12, Rick C wrote:
On Friday, November 8, 2019 at 5:48:04 PM UTC-5, Stef wrote:
On 2019-11-08 Rick C wrote in comp.arch.fpga:
On Friday, November 8, 2019 at 2:09:04 PM UTC-5, John Larkin wrote:

Please consider this a PHB type question. I don't do FPGA
development
myself, past whiteboarding.

Anyone know what a "PHB type question" is?

https://dilbert.com/search_results?terms=phb

Yeah, someone explained in the other group.  A bit obscure, methinks.


Nah.  I get suspicious of any engineer who doesn't know the term PHB!

It's like not understanding the term SEP.

I had to think a bit to come up with PHB, but I got it.  I've no idea
what SEP is.

"Somebody else's problem".  It's a term from Douglas Adams:

"""
An SEP is something we can't see, or don't see, or our brain doesn't let
us see, because we think that it's somebody else's problem. That’s what
SEP means. Somebody Else’s Problem. The brain just edits it out, it's
like a blind spot.
"""

https://en.wikipedia.org/wiki/Somebody_else's_problem


It is very useful in all kinds of engineering, for helping focus on the
task /you/ have to do instead of everyone else's tasks.


But then I'm acronymn dumb (and too lazy to try and google it right
now.)

You need to swat up on your TLA's Smile


"swot" up, rather - and I need to work on my spelling!

David Brown
Guest

Mon Nov 11, 2019 6:45 pm   



On 11/11/2019 17:33, gtwrek wrote:
Quote:
In article <qqb5mf$e1f$1_at_dont-email.me>,
David Brown <david.brown_at_hesbynett.no> wrote:
On 09/11/2019 00:12, Rick C wrote:
On Friday, November 8, 2019 at 5:48:04 PM UTC-5, Stef wrote:
On 2019-11-08 Rick C wrote in comp.arch.fpga:
On Friday, November 8, 2019 at 2:09:04 PM UTC-5, John Larkin wrote:

Please consider this a PHB type question. I don't do FPGA development
myself, past whiteboarding.

Anyone know what a "PHB type question" is?

https://dilbert.com/search_results?terms=phb

Yeah, someone explained in the other group. A bit obscure, methinks.


Nah. I get suspicious of any engineer who doesn't know the term PHB!

It's like not understanding the term SEP.

I had to think a bit to come up with PHB, but I got it. I've no idea
what SEP is.


"Somebody else's problem". It's a term from Douglas Adams:

"""
An SEP is something we can't see, or don't see, or our brain doesn't let
us see, because we think that it's somebody else's problem. That’s what
SEP means. Somebody Else’s Problem. The brain just edits it out, it's
like a blind spot.
"""

<https://en.wikipedia.org/wiki/Somebody_else's_problem>


It is very useful in all kinds of engineering, for helping focus on the
task /you/ have to do instead of everyone else's tasks.

Quote:

But then I'm acronymn dumb (and too lazy to try and google it right
now.)


You need to swat up on your TLA's :-)


Quote:

(I've got a feeling a "whoosh" at my expense is incoming...)

--Mark





Add Hunter
Guest

Wed Jan 22, 2020 7:45 am   



Grate site. New to Addhunters? It's incredibly easy to become a member of our community, and FREE to list your classified ads to interact with all members. Every day, hundreds of listings get listed for free by our Addhunters members. You can always upgrade your membership and get ahead of the crowd.. With Addhunters you're going to benefit from our international usages!Items listed on Add Hunters include electronics, pets, cars and, vehicles and other categories including land and property. The categories with the highest volume on the site are vehicles and property. For more details please visit our web site www.addhunters.comauto z qatar

Theo
Guest

Fri Apr 17, 2020 5:45 pm   



Grant Edwards <invalid_at_invalid.invalid> wrote:
Quote:
Once I got a UART working so I count print messages, I just gave up on
the JTAG BS. Another interesting quirk was that the Altera USB JTAG
interface only worked right with a few specific models of powered USB
hubs.


I've spent months working around such problems Sad
We have an application that pushes gigabytes through JTAG UARTs and have
learnt all about it...

There's a pile of specific issues:

- the USB 1.1 JTAG is an FT245 chip which basically bitbangs JTAG; it sends
a byte containing 4 bits for the 4 JTAG wires. The software is literally
saying "clock high, clock low, clock high, clock low" etc. Timing of that
is not reliable. Newer development boards have a USB 2.0 programmer
where things are a bit better here, but it's still bitbanging.

- being USB 1.1, if you have a cheap USB 2.0 hub it may only support USB SST
which means all USB 1.1 peripherals share 12Mbps of bandwidth. In our case
we have 16 FPGAs all trying to chat using that shared 12Mbps bandwidth.
Starvation occurs and nobody makes any progress.
A better hub with MST will allow multiple 12Mbps streams to share the
480Mbps USB 2.0 bandwidth. Unfortunately when you buy a hub this is never
advertised or explained.

- The software daemon that generates the bitbanging data is called jtagd and
it's single threaded. It can max out a CPU core bitbanging, and that can
lead to unreliability. I had an Atom where it was unusable. I now install
i7s in servers with FPGAs, purely to push bits down the JTAG wire.

- To parallelise downloads to multiple FPGAs, I've written some horrible
containerisation scripts that lie to each jtagd there's only one FPGA in
tte system. Then I can launch 16 jtagds and use all 16 cores in my system
to push traffic through the JTAG UARTs

- Did I mention that programming an FPGA takes about 700MB? So I need to
fit at least 8GB of RAM to avoid memory starvation when doing parallel
programming (if the system swaps the bitbanging stalls and the FPGA
programming fails)

- there's some troubles with jtagd and libudev.so.0 - if you don't have it
things seem to work but get unreliable. I just symlink libudev.so.1 on
Ubuntu and it seems to fix it.

- the register-level interface of the JTAG UART isn't able to read the state
of the input FIFO without also dequeuing the data on it. Writing
reliable device drivers is almost impossible. I have a version that wraps
the UART in a 16550 register interface to avoid this problem.

- if the FPGA is failing timing, the producer/consumer of the UART can break
in interesting ways, which look a lot like there's some problem with the USB
hub or similar.


It's a very precarious pile of hardware and software that falls over in
numerous ways if pushed at all hard :(

Theo
[adding comp.arch.fpga since this is relevant to those folks]

Rick C
Guest

Fri Apr 17, 2020 6:45 pm   



On Friday, April 17, 2020 at 12:18:35 PM UTC-4, Theo wrote:
Quote:
Grant Edwards <invalid_at_invalid.invalid> wrote:
Once I got a UART working so I count print messages, I just gave up on
the JTAG BS. Another interesting quirk was that the Altera USB JTAG
interface only worked right with a few specific models of powered USB
hubs.

I've spent months working around such problems Sad
We have an application that pushes gigabytes through JTAG UARTs and have
learnt all about it...

There's a pile of specific issues:

- the USB 1.1 JTAG is an FT245 chip which basically bitbangs JTAG; it sends
a byte containing 4 bits for the 4 JTAG wires. The software is literally
saying "clock high, clock low, clock high, clock low" etc. Timing of that
is not reliable. Newer development boards have a USB 2.0 programmer
where things are a bit better here, but it's still bitbanging.

- being USB 1.1, if you have a cheap USB 2.0 hub it may only support USB SST
which means all USB 1.1 peripherals share 12Mbps of bandwidth. In our case
we have 16 FPGAs all trying to chat using that shared 12Mbps bandwidth.
Starvation occurs and nobody makes any progress.
A better hub with MST will allow multiple 12Mbps streams to share the
480Mbps USB 2.0 bandwidth. Unfortunately when you buy a hub this is never
advertised or explained.

- The software daemon that generates the bitbanging data is called jtagd and
it's single threaded. It can max out a CPU core bitbanging, and that can
lead to unreliability. I had an Atom where it was unusable. I now install
i7s in servers with FPGAs, purely to push bits down the JTAG wire.

- To parallelise downloads to multiple FPGAs, I've written some horrible
containerisation scripts that lie to each jtagd there's only one FPGA in
tte system. Then I can launch 16 jtagds and use all 16 cores in my system
to push traffic through the JTAG UARTs

- Did I mention that programming an FPGA takes about 700MB? So I need to
fit at least 8GB of RAM to avoid memory starvation when doing parallel
programming (if the system swaps the bitbanging stalls and the FPGA
programming fails)

- there's some troubles with jtagd and libudev.so.0 - if you don't have it
things seem to work but get unreliable. I just symlink libudev.so.1 on
Ubuntu and it seems to fix it.

- the register-level interface of the JTAG UART isn't able to read the state
of the input FIFO without also dequeuing the data on it. Writing
reliable device drivers is almost impossible. I have a version that wraps
the UART in a 16550 register interface to avoid this problem.

- if the FPGA is failing timing, the producer/consumer of the UART can break
in interesting ways, which look a lot like there's some problem with the USB
hub or similar.


It's a very precarious pile of hardware and software that falls over in
numerous ways if pushed at all hard :(

Theo
[adding comp.arch.fpga since this is relevant to those folks]


I guess once your design becomes complex enough it isn't so practical to debug it in the HDL simulator. Eh?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

Theo
Guest

Fri Apr 17, 2020 9:45 pm   



Rick C <gnuarm.deletethisbit_at_gmail.com> wrote:
> I guess once your design becomes complex enough it isn't so practical to debug it in the HDL simulator. Eh?

We have boxes of 16 and a rack of 80 FPGAs, and this is used for data
onload/offload not debugging. So the simulator won't do ;-P

Theo

Rick C
Guest

Fri Apr 17, 2020 10:45 pm   



On Friday, April 17, 2020 at 4:19:49 PM UTC-4, Theo wrote:
Quote:
Rick C <gnuarm.deletethisbit_at_gmail.com> wrote:
I guess once your design becomes complex enough it isn't so practical to debug it in the HDL simulator. Eh?

We have boxes of 16 and a rack of 80 FPGAs, and this is used for data
onload/offload not debugging. So the simulator won't do ;-P

Theo


Have you thought of putting it all into one really big FPGA? 8-o

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

Goto page Previous  1, 2, 3 ... 362, 363, 364

elektroda.net NewsGroups Forum Index - FPGA - EDK : FSL macros defined by Xilinx are wrong

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map