EDK : FSL macros defined by Xilinx are wrong

[David Brown]

On 17/12/2018 16:02, frankcovending@gmail.com wrote:

On Monday, December 17, 2018 at 9:31:21 AM UTC-5, David Brown wrote:
On 17/12/18 13:40, wrote:
I've spent hours searching and kept coming up empty. I've found all
of the manuals and all software through google, but that 8051
compiler just isn't easy. You are probably right that replying to old
emails etc is not going to get me far, but it is a resource and I'm
going to exhaust all of them. I'll look into the resources you have
provided.


A compiler is entirely different from a disassembler. You said "I am
looking for some disassemblers too. 8051 in particular". Now you say
you want a compiler. Which is it?

There are /lots/ of compiler for the 8051. Many commercial ones, and at
least one solid open source one. I don't know about disassemblers for
the core, having never needed to use one, but google finds plenty within
a few seconds.

You need to figure out what tool(s) you are actually looking for - or at
least figure out what you want to do with them. You need to figure out
whether you are dealing with the core in general, or specific devices,
whether you want commercial tools or free ones, and so on.

And if you want help from people, you will have to say what you have
tried so far and why those tools have been inappropriate. Otherwise no
one can help.

But as I say, please drop the "Google Groups" interface - it is
absolutely terrible for posting to Usenet (though it is okay for
searching archives). If you can't use a proper Usenet client, then at
least learn to use Google Groups properly - it's default options are
contrary to standard Usenet usage. (This is not your fault, it is
Google's fault - but it is you, the GG poster, who has to make the
effort.) Quote posts correctly, with attribution and appropriate
snipping, and split your lines correctly.

And then, when you have this figured out, post to comp.arch.embedded -
it is the best newsgroup for such tools. (comp.arch.fpga is a fine and
helpful group too, but c.a.e. will reach more 8051 users.)

My mistake on my prior reply. I did not intend to say compiler. I
meant to say disassembler. My mistake, human...

OK.

I get what you're saying about everything being on google, but it's a
tool not the means to an end. I'm trying to get my hands on the 8051
disassembler for the pm3585 logic analyzer. I'm trying to learn how to
debug the 8051 using the pm3585.

Is this for a history project, or a museum? Nobody has used a logic
analyser for microcontroller debugging for at least 20 years, probably more.

Now I have been out of the electronics/computer field for quite some
time and I had shifted my focus to mechanical and civil engineering. I
am just getting back into hobby electronics. I am working on some
mechatronics project at home in my free time and I'm prototyping with
off the shelf controllers, but my goal is to develop my own controller
and I am tempted to use the 8051 or a Z80. I'm leaning towards the 8051
because the DS89C4XX has everything I need and I have the components
from a sample pack I got almost a decade ago. I have a Z80 as well.

The 8051 is 40 years old, and the architecture was outdated before the
first chip was made. There have been some reasonable microcontrollers
made around it, despite it's horrendous core. And the Z80 was a fine
device 30 years ago.

What you are suggesting is like trying to build a car using a steam engine.

I can appreciate that there is some nostalgia in this for you, but I
really would recommend using newer hardware and software. Probably the
best choice for getting started would be an Arduino kit - there are lots
of base boards to choose from, lots of add-ons, lots of tutorials and
examples, and a reasonable IDE (which is free).

 

On Monday, December 17, wrote:

On Monday, December 17, 2018 at 9:31:21 AM UTC-5, David Brown wrote:
On 17/12/18 13:40, wrote:
I've spent hours searching and kept coming up empty. I've found all
of the manuals and all software through google, but that 8051
compiler just isn't easy. You are probably right that replying to old
emails etc is not going to get me far, but it is a resource and I'm
going to exhaust all of them. I'll look into the resources you have
provided.


A compiler is entirely different from a disassembler. You said "I am
looking for some disassemblers too. 8051 in particular". Now you say
you want a compiler. Which is it?

There are /lots/ of compiler for the 8051. Many commercial ones, and at
least one solid open source one. I don't know about disassemblers for
the core, having never needed to use one, but google finds plenty within
a few seconds.

You need to figure out what tool(s) you are actually looking for - or at
least figure out what you want to do with them. You need to figure out
whether you are dealing with the core in general, or specific devices,
whether you want commercial tools or free ones, and so on.

And if you want help from people, you will have to say what you have
tried so far and why those tools have been inappropriate. Otherwise no
one can help.

But as I say, please drop the "Google Groups" interface - it is
absolutely terrible for posting to Usenet (though it is okay for
searching archives). If you can't use a proper Usenet client, then at
least learn to use Google Groups properly - it's default options are
contrary to standard Usenet usage. (This is not your fault, it is
Google's fault - but it is you, the GG poster, who has to make the
effort.) Quote posts correctly, with attribution and appropriate
snipping, and split your lines correctly.

And then, when you have this figured out, post to comp.arch.embedded -
it is the best newsgroup for such tools. (comp.arch.fpga is a fine and
helpful group too, but c.a.e. will reach more 8051 users.)

My mistake on my prior reply. I did not intend to say compiler. I
meant to say disassembler. My mistake, human...

OK.


I get what you're saying about everything being on google, but it's a
tool not the means to an end. I'm trying to get my hands on the 8051
disassembler for the pm3585 logic analyzer. I'm trying to learn how to
debug the 8051 using the pm3585.


Is this for a history project, or a museum? Nobody has used a logic
analyser for microcontroller debugging for at least 20 years, probably more.


Now I have been out of the electronics/computer field for quite some
time and I had shifted my focus to mechanical and civil engineering. I
am just getting back into hobby electronics. I am working on some
mechatronics project at home in my free time and I'm prototyping with
off the shelf controllers, but my goal is to develop my own controller
and I am tempted to use the 8051 or a Z80. I'm leaning towards the 8051
because the DS89C4XX has everything I need and I have the components
from a sample pack I got almost a decade ago. I have a Z80 as well.


The 8051 is 40 years old, and the architecture was outdated before the
first chip was made. There have been some reasonable microcontrollers
made around it, despite it's horrendous core. And the Z80 was a fine
device 30 years ago.

What you are suggesting is like trying to build a car using a steam engine.

I can appreciate that there is some nostalgia in this for you, but I
really would recommend using newer hardware and software. Probably the
best choice for getting started would be an Arduino kit - there are lots
of base boards to choose from, lots of add-ons, lots of tutorials and
examples, and a reasonable IDE (which is free).

I see and I do agree. I just happen to have a load of these 8051 chips and other outdated pieces and I would rather put them to use than chuck them. I was eyeballing the arduino uno though.

I guess I'll just try to develop and if things get rough I'll just give it the old college try w or w/o disassembler. I'f I am careful I might be able, haha, to get away with a bug free piece.

Thanks for your interest in my problem

 

[Nicolas Matringe]

On 17/12/2018 22:39, David Brown wrote:

Is this for a history project, or a museum?  Nobody has used a logic
analyser for microcontroller debugging for at least 20 years, probably
more.

As a matter of fact I did 3 years ago. It was a Xilinx picoBlaze and
that was the only way I had to trace the execution. It was fun.

Nicolas

 

[David Brown]

On 18/12/18 21:50, Nicolas Matringe wrote:

On 17/12/2018 22:39, David Brown wrote:

Is this for a history project, or a museum? Nobody has used a logic
analyser for microcontroller debugging for at least 20 years, probably
more.

As a matter of fact I did 3 years ago. It was a Xilinx picoBlaze and
that was the only way I had to trace the execution. It was fun.

Nicolas

I admit that "nobody" was an exaggeration. But it is has certainly
become very rare as a debugging technique.

Note that we are not talking about using a logic analyser for monitoring
the outputs from a microcontroller in order to find out if the program
is running correctly - lots of people do that. (Though they usually use
little USB-connected pods and PC software, rather than huge and
expensive dedicated machines.) This was about using a logic analyser to
trace the entire instruction stream - with a disassembler interpreting
the stream. It is something that could be done in the days of external
ROM for your code and simple, non-pipelined deterministic cpu cores.

 

I'll state my reason for using a dedicated machine. I do not like software based diagnostics. The problem comes when the developer stops updating the software. Then you need to buy new hardware and software. With a dedicated stand alone machines even after 20 years it works. To me it is a way to avoid getting cornered into license fees, obsolescence. I have Micro-Cap from back in the Dos days on a 5-1/4 floppy... I don't have a machine to run it but I have it.

That's why I like my hardware. I actually own it to rather than paying for the right to use (like most proprietary software).

 

[kkoorndyk]

On Wednesday, June 12, 2019 at 7:34:09 PM UTC-4, John Larkin wrote:

Assume I'm a pointy-haired boss trying to help one of my guys.

I think that...

The Xilinx ZYNQ (FPGA+ARM on a chip) has a hard boot loader. It
figures out what the boot device is (serial flash, SD card, whatever)
and reads in a secondary boot program, which the Xilinx tools provide
as part of a build. That loader then reads the entire FPGA config
bitstream into DRAM, and sets up a giant DMA transfer to configure the
FPGA. That's all standard in the tools.

But what if there's no DRAM? My guy thinks he will have to write his
own ARM application, which is booted at load time, and inside that
would be a routine to read from the boot media and configure the FPGA
in chunks, using a small uP RAM buffer, maybe DMA or maybe not. He
figures he could do that in a few days.

Seems to me that Xilinx should support booting up a ZYNQ without DRAM.
Does the tool chain support that (people here think not) or is there
some loader already coded somewhere?

(Our support, through a distributor, isn't very good.)

Thanks





--

John Larkin Highland Technology, Inc
picosecond timing precision measurement

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

You're in the Bay Area, right? I've had good experiences with the Avnet Xilinx FAEs out there. I can put you in touch with some folks if you need.

There is a reference design for running out of On-Chip Memory (OCM):
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842377/Zynq-7000+AP+SoC+Boot+-+Booting+and+Running+Without+External+Memory+Tech+Tip

It's worth reviewing UG585 - Zynq-7000 SoC TRM, Chapter 6: Boot and Configuration as well. Section 6.4 - Device Boot and PL Configuration is particularly helpful here.
https://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf

In a lot of cases, the PL is configured by the FSBL, which can be run from OCM and it's rather trivial to enable that in the Xilinx SDK.

 

[Bart Fox]

As others mentioned: there is 256kByte OCM on Zynq.
I assume you want configure the device from flash.

Step 1: FSBL
Step 2: start u-boot (with fpga configuration support)
Step 3: configure u-boot to configure the fpga
Step 4: let u-boot load and start your bare metal application

Bart Fox

 

Hi,
I would be highly interested in the PM3585 disassembler software

Regards
smed

 

On Wednesday, August 28, 2019 at 4:13:03 PM UTC-4, sm...@none.i2p wrote:

Hi,
I would be highly interested in the PM3585 disassembler software

Regards
smed

Which ones?

 

[Rick C]

On Friday, November 8, 2019 at 2:09:04 PM UTC-5, John Larkin wrote:

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.

Anyone know what a "PHB type question" is?

--

Rick C.

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

 

On Friday, November 8, 2019 at 1:09:04 PM UTC-6, John Larkin wrote:

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]

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

--
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]

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.

--

Rick C.

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

 

[David Brown]

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.

 

[gtwrek]

In article <qqb5mf$e1f$1@dont-email.me>,
David Brown <david.brown@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.

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]

On 11/11/2019 18:10, David Brown wrote:

On 11/11/2019 17:33, gtwrek wrote:
In article <qqb5mf$e1f$1@dont-email.me>,
David Brown  <david.brown@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

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

 

[David Brown]

On 11/11/2019 17:33, gtwrek wrote:

In article <qqb5mf$e1f$1@dont-email.me>,
David Brown <david.brown@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

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

--Mark

 

[Add Hunter]

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.com<a href="http://www.addhunters.com">auto z qatar</a>

 

[Theo]

Grant Edwards &lt;invalid@invalid.invalid&gt; 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
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]

On Friday, April 17, 2020 at 12:18:35 PM UTC-4, Theo wrote:

Grant Edwards &lt;invalid@invalid.invalid&gt; 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
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