EmbDev.net

Forum: FPGA, VHDL & Verilog looking for the MIPS1 PH project v2


Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
hi guys
googling i have found this (1) project that seems very very interesting, 
P.H. stands for "Patterson-Hennessy", so it looks a very good 
didactical thing, btw following its link i have reached this (2) web-url 
that is provided by Embedded Systems Laboratory, Department of 
Engineering of the University of Leicester (UK), and reading their web 
page i have seen the following:

> http://www.le.ac.uk/eg/embedded/PH%20files/images/...
> Available files include:
> PH ISE project file and VHDL source code
> ZCV binary file splitter
> VB PH Debug application
> Example C source code
> Link to GCC tools

that's cool !!! Unfortunately the download link is broken and the email 
contact is obsoleted.

Anyone that has downloaded this material, PH Version2 ? If so, could 
share with me ?

let me know, thanks


(1) 
http://www.le.ac.uk/eg/embedded/PH%20files/files/T...

(2)
http://www.le.ac.uk/eg/embedded/PH.htm

: Edited by User
Author: greg (Guest)
Posted on:

Rate this post
0 useful
not useful
Looks like that is a pipelined MIPS implementation, though? :)

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
yes, it is pipelined, my interest about this implementation is about the 
"debug module", i'd like to see how it is implemented, also the host 
debugger part seems interesting (although … i have read that it has been 
developed in Visual Basic, brrr)

: Edited by User
Author: Strubi (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi,

concerning Debugging: There are some links to an older presentation 
here:
http://tech.section5.ch/news/?p=251

The MIPS standard EJTAG approach is very bloated, it's much easier to 
follow some simple emulation techniques as demonstrated.

Cheers,

- Strubi

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
yeah, EJTAG approach is very bloated, i simply do not like it.

about the gdb-stub approach, well i thing i think the ugly of this is 
that filling break instruction to force a breakpoints, also you can't 
trust the firmware (the gdb-stub side) when your soft core is not 
validated, yet.

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
about the article

> ...
> This enabled us to connect to a hardware ZPU core
> with the GNU debugger like we would attach to the emulator.
> ...

i am afraid this is not correct!

> The same has been implemented for the ADI Blackfin family
> for a long time.

i have bought a blackfin BF537 development board with its 
cheap(1)-usb-jtag-B1000, this jtag is composed by a tiny board in where 
a second BF53x chip sits, that's cool, i have a jtag which is composed 
by the same DSP it aims to debug for :D

the magic of this is that the DSP on the cheap-jtag-cable is running a 
sort of software emulation of the expensive-jtags (they may cost up to 
$4000 USD), so the point is: the dsp in the cheap-usb-jtag is a sort of 
"debug processor" used to debug the real target!

(1) it costs about 200 euro (VAT applied), that is really expensive for 
me, while AnalogDevices says it is the cheapest they have for blackfin, 
the so called "relativity" =D

: Edited by User
Author: Strubi (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi,

>> ...
>> This enabled us to connect to a hardware ZPU core
>> with the GNU debugger like we would attach to the emulator.
>> ...
>
> i am afraid this is not correct!

I'm afraid it is. I've implemented it :-)

>
>> The same has been implemented for the ADI Blackfin family
>> for a long time.
>
> i have bought a blackfin BF537 development board with its
> cheap(1)-usb-jtag-B1000, this jtag is composed by a tiny board in where
> a second BF53x chip sits, that's cool, i have a jtag which is composed
> by the same DSP it aims to debug for :D
>
> the magic of this is that the DSP on the cheap-jtag-cable is running a
> sort of software emulation of the expensive-jtags (they may cost up to
> $4000 USD), so the point is: the dsp in the cheap-usb-jtag is a sort of
> "debug processor" used to debug the real target!
>
> (1) it costs about 200 euro (VAT applied), that is really expensive for
> me, while AnalogDevices says it is the cheapest they have for blackfin,
> the so called "relativity" =D

ADI is running a puzzling scheme with respect to their tools. Even after 
10 years, they haven't sorted out their toolchain problems. This is 
another topic though.

Legacy My wrote:
> about the gdb-stub approach, well i thing i think the ugly of this is
> that filling break instruction to force a breakpoints, also you can't
> trust the firmware (the gdb-stub side) when your soft core is not
> validated, yet.

In fact, I use emulation to validate the soft core. This is a multi 
stage approach, really. Not going to go into details, but after first 
validation of all implemented instructions, the core is burn-in-tested 
in hardware (because simulation would be too slow) using test patterns 
via JTAG. One method emulates/verifies the pipeline, the other (relevant 
to the user) verifies the debugger usage (memory writes, exception 
robustness, nonintrusiveness, etc).

There's nothing wrong with using a "break" instruction for soft breaks. 
This is GDB standard technique. If you want hbreaks, you'd have to use a 
watchpoint unit (which is mostly architecture independent). On an FPGA 
soft core running programs from block RAM, a WP unit is normally 
overkill.


Greetings,

- Strubi

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
> In fact, I use emulation to validate the soft core. This is a multi
> stage approach, really.

have you validated the ZPU ? Great =D

I got a similar validation problem with a RISC-MIPS-like cpu and … i am 
looking for the best way to fix the jam. With a friend of mine we have 
recently found 2 bugs in the RTL level of the hazard detect unit, and … 
we suspect other bugs around. Simulating things is very ugly, boring, 
and … terribly slow.

could i ask you more details about (in private, if you prefer, in case 
my email is carlojpisani at gmail dot com)

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
> There's nothing wrong with using a "break" instruction for soft breaks.
> This is GDB standard technique.

Which is the difference between Harvard Architecture and von Neumann 
Architecture?

The most obvious characteristic of the Harvard Architecture is that it 
has physically separated signals and storage for code and data memory, 
so it is possible to access program memory and data memory 
simultaneously (that is extremely good for pipelining because it can do 
pre-fetch). Typically, code space is read-only and data memory is 
read-write. Therefore, it is impossible for program contents to be 
modified by the program itself.

The von Neumann Architecture is named after the mathematician and early 
computer scientist John von Neumann and Neumann machines have shared 
signals and memory for code and data. Thus, the program can be easily 
modified by itself since it is stored in read-write memory.

What does it means for SoC ? That if you want to use break instruction … 
you need
1) your soft core needs to be developed in the von Neumann Architecture 
way
2) if your soft core is Harvard Architecture … then you need a dual-port 
ram to brings the data-space (which is accessible by all the load/store 
instruction) in order to write the 4 byte break-instruction in the 
instruction-space

Also the gdb-host side needs to hardly synchronized to the debug code, 
in order to remove the break instruction from iram replacing the 
original byte s-code.

: Edited by User
Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
p.s.
about Harvard Architecture .. can you imagine how ugly it goes if you 
have iram sitting into flash (like AVR8, aka Atmel Arduino1 core) ? As 
flash are organized in "banks" (chunks of bytes, or word, of you prefer) 
to insert/remove break instruction you have

- to erase the whole flash bank
- to reprogram the whole flash bank

: Edited by User
Author: Strubi (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi,

> have you validated the ZPU ? Great =D

Nope, I was talking about a MIPS core (rewritten from scratch using 
MyHDL).
Afraid it's pipelined though. I could validate the ZPU through the same 
emulation interface, but I assume that has been done. For me, it just 
works.

>
> I got a similar validation problem with a RISC-MIPS-like cpu and … i am
> looking for the best way to fix the jam. With a friend of mine we have
> recently found 2 bugs in the RTL level of the hazard detect unit, and …
> we suspect other bugs around. Simulating things is very ugly, boring,
> and … terribly slow.

Well, I guess I've just got this advice: If it's broken and from someone 
else, don't bother fixing it. Rewrite the whole shlorm :-)

Speaking about Harvard and vNeumann: You're correct, but we're still on 
an FPGA, right? My MIPS implementation is kinda modified Harvard, like 
the Blackfin. Either dual port RAM is used (required for MIPS16 arch as 
well for pc relative addressing), or DMA gets access to Program memory.
GDB does all the SW breakpoint handling for you, if you specify the 
backend correctly. In this case I'm just using a standard mips-elf-gdb 
to debug the SoC.

You're completely free to implement WP units for HW breakpoints, but I 
would start with the simple things first...

- Strubi

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
> Nope, I was talking about a MIPS core
> (rewritten from scratch using MyHDL).

which one ? is this MIPS-core public || available ?


> Afraid it's pipelined though

don't worry about this, i have already written my toy-multi-cycle (1) in 
order to toy/study with my uart debug module


(1) actually it has a reduced MIPS1 ISA
- lw, sw, lb, sw
- beq, bne
- j, jall
- add, sub, or, and
- lui, li
- addi, subi, ori, andi

i don't think i will add other instructions
it may be i will add just {break, syscall, something about cop0}

it's an easy toy and must be easy for its definition of "toy"



> Well, I guess I've just got this advice: If it's broken and from someone
> else, don't bother fixing it. Rewrite the whole shlorm :-)

in same case it is a MUST (especially if the original author has 
confused ideas in his/her mind), but … there is an other must that must 
be considered first: why to reinvent the wheel ? also … for example MAIS 
is a great work, and if it has bugs in the RTL level … you'd better fix 
them than think about  rewriting the whole from scratches, don't you 
think it is better ?


> Speaking about Harvard and vNeumann: You're correct, but we're still on
> an FPGA, right? My MIPS implementation is kinda modified Harvard, like
> the Blackfin. Either dual port RAM is used

i applied the same patch (dual port ram to iram, in order to map it to 
dram space, "i" stands for instruction-ram, "d" stands for data-ram) to 
the Mais scheme with success, this makes gdb-stub able to work. Just an 
idea, a proof of the concept, because i think that to use gdb-stub 
(which is firmware) you have to trust the RTL level, and … this is not 
compatible with soft cores that have bugs in the RTL level: the gdb-stub 
is requiring interrupts, so … i am afraid it will look like a bloody 
fight nightmare if the RTL is bugged, and this is also a contradiction 
to the purpose, which is to find out a way to fix the RTL from its bugs!


> You're completely free to implement WP units for HW breakpoints, but I
> would start with the simple things first

that is a good idea!

: Edited by User
Author: Strubi (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi,

>
> which one ? is this MIPS-core public || available ?
>

Not public, I'm afraid. It's used commercially. Might release an 
"academic toy" variant some time (as you call it :-) ). It's kinda fun 
to play with a virtual CPU, actually (see also 
http://www.section5.ch/doc/jtag/movies/, these were done for the ZPU, 
same works on MIPS these days).

>
> in same case it is a MUST (especially if the original author has
> confused ideas in his/her mind), but … there is an other must that must
> be considered first: why to reinvent the wheel ? also … for example MAIS
> is a great work, and if it has bugs in the RTL level … you'd better fix
> them than think about  rewriting the whole from scratches, don't you
> think it is better ?
>

Depends on how maintainable the code is. Turned out that the validation 
and testing overhead was far easier to master by a complete rewrite in 
another language. Writing a full SoC in VHDL/Verilog is compareable to 
writing a parser in assembler, once you got used to MyHDL.

> i applied the same patch (dual port ram to iram, in order to map it to
> dram space, "i" stands for instruction-ram, "d" stands for data-ram) to
> the Mais scheme with success, this makes gdb-stub able to work. Just an
> idea, a proof of the concept, because i think that to use gdb-stub
> (which is firmware) you have to trust the RTL level, and … this is not
> compatible with soft cores that have bugs in the RTL level: the gdb-stub
> is requiring interrupts, so … i am afraid it will look like a bloody
> fight nightmare if the RTL is bugged, and this is also a contradiction
> to the purpose, which is to find out a way to fix the RTL from its bugs!
>

Well, for one thing, I would strongly recommend not to implement a 
debugger as on-SoC-gdb-stub. This is very error prone, too intrusive and 
problematic WRT testing as you point out. The in-circuit-emulation 
approach is way more elegant and even simpler to implement (based on 
JTAG or other Test-Access-Port protocols via a gdbproxy interface). It's 
described in various papers, but basically you only have to (re/ab)use 
working exception mechanisms to implement it. If not existing, you 
automatically implement proper exception handling when implementing ICE. 
The MAIS architecture is not really laid out for ICE, although I had a 
functional ICE workaround for it.

Cheers,

- Strubi

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
> The in-circuit-emulation approach is way more elegant
> and even simpler to implement

ok, good advice, i will follow it, thank you =)

> It's described in various papers

i am new to these things, up today i have always "used" jtag and bdm 
(motorola m68332 / freescale coldfire) as "user", i have never 
implemented such a stuff.

> The MAIS architecture is not really laid out for ICE, although I had a
> functional ICE workaround for it.

it may be a good example, can i see it for educational purpose ?

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
is there around any good and simple jtag or bdm module, with a bit of 
documentation and HTL sources ?

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
what about putting a tiny debug-processor inside the SoC (just near the 
main Softcore) ?

Assuming you have enough resources to put two soft core inside your fpga 
(a smaller debug-processor-Softcore, very essential and tiny, and .. a 
potential elephant big Softcore plus its devices, rams, etc etc, … i 
think a spartan3e-500 may not be enough but a 1600 could be), we are 
speaking about something that can
- blocks the Main Softcore's clock, at a particular PC, or .. just every 
its fetches to do step by step instead of breakpoint debugging
- access (reading/writing) the Main Softcore's registers (also to PC, 
EPC, cause, cop0 and whatever …)
- access (reading/writing) the Main Softcore's local bus (so r/w its 
iram/dram)

the idea is to put gdb-stub inside the tiny Debug Processor (which is 
validated, so you can trust it), and let it to (uart-serially-)-talk 
gdb-protocol with the host in order to control the target !

in this ways you put much more intelligence in the debug module, which 
could simplify things like … attaching the host in order to control 
things

with a gdb-debug-processor the host could simply send commands (high 
level commands, also in pretty ASCII form) and gets replies instead of 
hardly handling all the signals of a jtag tap machines (which also 
requires … a special file that describe the target from the point of 
view of the TAP machine)

what do you think ?

: Edited by User
Author: Duke Scarring (Guest)
Posted on:

Rate this post
0 useful
not useful
Legacy My wrote:
> what do you think ?

A JTAG/BSCAN-FSM is just the perfect debug processor...

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
> A JTAG/BSCAN-FSM is just the perfect debug processor...

i do not think about that because
1) you have to deal with BSDL files, which can be very complex/difficult 
to have/write/use
2) you have to deal with a low level protocol (such the jtag is) that is 
slow and which requires a lot of cares about the SoC main clock
3) the host side is … difficult, too, and you have to deal with USB-jtag 
adaptor and their driver/handler etc etc


a debug processor which talks ascii protocol over the uart is simply 
"easy", portable, good to be understood, fast, and … easy to be 
adapted/interfaced with gdb

: Edited by User
Author: Martin S. (strubi)
Posted on:

Rate this post
0 useful
not useful
Legacy My wrote:
>> A JTAG/BSCAN-FSM is just the perfect debug processor...
>
> i do not think about that because
> 1) you have to deal with BSDL files, which can be very complex/difficult
> to have/write/use

Nope, this has nothing to do with BSDL. Look at the paper I've sent you.
Either you use the built-in JTAG primitive or implement your own FSM.

> 2) you have to deal with a low level protocol (such the jtag is) that is
> slow and which requires a lot of cares about the SoC main clock

Nah, that's easy. If you do not need to "live" poll the PC or specific 
counters, you don't even need cross clock domain syncing. The JTAG state 
machine allows for enough handshaking. On the MIPS, a program loads 
within fractions of a second onto the target using emulation (memory 
write commands).

> 3) the host side is … difficult, too, and you have to deal with USB-jtag
> adaptor and their driver/handler etc etc
>

Ok, that's stuff you have to do once. There's a bunch of tools around 
(OpenOCD, various gdbproxy implementations for FTDI adapters, etc.)

>
> a debug processor which talks ascii protocol over the uart is simply
> "easy", portable, good to be understood, fast, and … easy to be
> adapted/interfaced with gdb

Well, if you think so, then go ahead and write one. There's just one 
dogma in the debugger's world: You don't wanna go and debug your 
debugger.

IMHO, gdbstubs over UART are completely useless on an FPGA. You'll have 
to deal with proper timeouts, etc. All serial gdb stubs I've seen so far 
were broken by design and very unstable (this due to some serious gdb 
design flaws, however they can be worked around by ethernet).
Put the intelligence in your host side, not the FPGA!

Cheers

- Strubi

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
is it possible to see a working example ? i mean source code, script, 
and something i can put, on my toy-fpga ?

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
Strubi wrote:
> follow some simple emulation techniques as demonstrated.

where has it been demonstrated by examples ? i can only see this (1) 
skimpy article.


(1) http://tech.section5.ch/news/?p=251

Author: Strubi (Guest)
Posted on:

Rate this post
0 useful
not useful
I've sent you all you need to have to implement your own debugger basing 
on the approach from the ZPU debug branch. So, please don't keep asking 
the same question over and over again. You need to dig into the details, 
others won't do it for you.

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
Strubi wrote:
> I've sent you all you need to have to implement your own debugger basing
> on the approach from the ZPU debug branch.

you have sent me a poor skimpy paper without any example or code, your 
skimpy pdf is useless at all, it is much more a brochure to sell a 
product than a technical paper, there are no details, no documentation, 
nothing at all.

> So, please don't keep asking the same question over and over again.

first of all i am free to ask whatever i want and how many times i want 
(also you are not the only one, others can contribute, giving answers), 
second i am asking things because they are not clear at all

> You need to dig into the details, others won't do it for you.

well, to be honest i am also thinking you have nothing working and you 
are telling bullshit just in order to open doors with business.

in short: bye-bye

: Edited by User
Author: Strubi (Guest)
Posted on:

Rate this post
0 useful
not useful
Ok, here's a few last comments:

- Showing off the little tantrums does not help. You have gotten enough 
help already.
- Debug tools are simply not free. My advices are.
- Learn to behave before you visit this forum again and get informed who 
you're talking to.

Immature people like you are mainly the reason why I stopped handing out 
valuable source code in the first place.

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
-1 useful
not useful
> Ok, here's a few last comments:

i hope it is the last time i have to read you!

You have trashed a lot of my time

> - Showing off

nothing useful


> - Debug tools are simply not free. My advices are.

Unfortunately, you are missing you are dealing about OpenSource things 
and you are posting in a forum where people is interested about such a 
things

you seem to use this forum to claim about your private business, perhaps 
this is useful for you, but how can be useful to others ?

> - Learn

learn respect!

> Immature people like you are mainly the reason why I stopped handing out
> valuable source code in the first place.

Yeah, just the last one comment: i am really sure you have nothing of 
what you claimed "ready and working" as i hope you are just trolling to 
business doors, about "reason" you look like the ones-fellows that grab 
other's people work in order to close things into their dirty business, 
that means you take other's people effort for free! It is not correct.

Btw, for such a reason, hope never see you again in my threads!

: Edited by User
Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
it seems to me there is a good OpenSource and Documentation around 
Lattice LM32, which also provide a debug module plus its host side.

Pretty to know that, writing this note in the hope it could help people 
like me (student with a limited know/how, learning needed, still in 
progress)

Author: Michael Fischer (mifi)
Posted on:

Rate this post
0 useful
not useful
In case of the LM32, Lattice use the hard coded JTAG primitive of the
FPGA. Perhaps this can be rebuild by VHDL/Verilog to make it usable
for other FPGAs.

In this case an OpenSource CPU with a complete Ecosystem would be
available?!

Regards,
Michael

Author: FPGAuser (Guest)
Posted on:

Rate this post
0 useful
not useful
>
> In this case an OpenSource CPU with a complete Ecosystem would be
> available?!
>

Ecosystem sound interesting.

What would it have?

only simply parts?
Eco reduce to basic?!

or simply recycleable for different applications?

Author: Michael Fischer (mifi)
Posted on:

Rate this post
0 useful
not useful
Hello ???,

I understand under "Ecosystem" a full functional system with Compiler,
Debugger and so on. Yes "Ecosystem" could be to colored and bloomy.
I mean a working toolchain. In case of LM32 it is available for the
Lattice platform. Nios for Altera and Microblaze for Xilinx. Even
there exist free RTOS and network stacks which can working on FPGAs.

E.g. there exists working toolchains for ARM, even with debugger.
In 2006 I started YAGARTO because there was no free working windows
native solution available. Where even the debugger was working under
Eclipse.

I think it is the same problem with the free OpenSource softcore
solution now. There exist no smooth working solution. Of course you
can use the CPU from the FPGA manufacture. Even you will find some
on OpenCores, but does there exist a complete toolchain where
the functionality can be compared against an hardcore CPU?

Even it could be possible that all the MIPS and other softcores are
only a playground in the academic research. But why does not exist
a free FPGA/JTAG debug solution whereas more people has started with
an own CPU?

I think if there exist a free smooth working toolchain and a free
CPU core. It will be easier to start porting the application to
this solution.

Regards,
Michael

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
> I think it is the same problem with the free OpenSource softcore
> solution now. There exist no smooth working solution. Of course you
> can use the CPU from the FPGA manufacture. Even you will find some
> on OpenCores, but does there exist a complete toolchain where
> the functionality can be compared against an hardcore CPU?

well, for Soft Core MIPS1 compliant it is possible (and i already did) 
to realize a full working toolchain composed by

1) GNU binutils, assembler, linker, objcopy objdump (these are useful to 
manipulate the final binary in order to upload it to the target or to 
embedded it into VHDL)

2) GNU C compiler, aka gcc, it is tricky for MIPS1 but it works

what is still missing ? all the debug side!

gdb-mips can be cross-compiled for host in order to remote-connect to a 
gdb-stub running inside the soft core, but this part is … simply wrong 
by its definition!

you can not trust a firmware like gdb-stub until you are pretty sure 
your soft core is pretty and full validated (which is false during the 
development stages)! Also gdb-stub work has stalled for a few years (i 
can show it with my ATLAS board, it has gdb-stub in its firmware, it is 
NOT compatible with modern gdb's protocol) and one of the problems is 
that gdb serial protocol has evolved, but documentation didn't … what is 
around the web is crippled gdb-stub known that not all functions worked 
and will work.

extremely care is needed about this


> Even it could be possible that all the MIPS and other softcores are
> only a playground in the academic research.

yes, all i have seen about MIPS is

1) mono cycle -> academic material, not really usable for real fpgas, 
not compliant with any MIPS1 class (they use to have an extremely 
reduced ISA, to reduced that it is impossible to retarget gcc/lcc or 
whatever C compiler), practically used within HDL simulators to teach 
computer science

2) multi cycle (not pipelined), it is the advance version of 1), used in 
advanced university courses, still not usable in practical things

3) the pipelined approach is pure theory in universities, because it is 
too difficult and it requires to much effort to be handled in 
laboratories. All is existing is … hobbits project for the most (with 
exceptions, like the LM32, which was developed by a Company), btw, some 
are good, same are not, and they are used not to be trusted as 
"validated", that means you are not sure they are really working without 
bad behaviors! Also … practically they use to miss the debug side (no 
ICE/TAP). ZPU and LM32 are exceptions, they comes with a pretty TAP 
inside, but they are not MIPS.

3) virtual systems, e.g. SPIM, EDUMIPS64, softwares that run on 
workstation and try to teach you about assembly programming the MIPS, 
the must of these soft wares are still not exactly MIPS1-compliant, e.g. 
SPIM has no delayed slot and it is missing a few opcodes, so you'd 
better program it in assembly, as suggested by the SPIM ambient.


> But why does not exist a free FPGA/JTAG debug solution
> whereas more people has started with an own CPU?

probably because guys are using jtag/BDM/etc with real ASIC, so the 
effort has been taken this way instead of thinking/writing/debugging 
around Soft Core. I can't provide a better explanation, but i am really 
thinking the debug things are not easy, they go very complex, so … i am 
afraid an other reason of this … may be that this things are not a piece 
of cake for the rest of us, and only Guru-addicted-guys can =(


> I think if there exist a free smooth working toolchain and a free
> CPU core

usually they exist, but be in mind that "toolchain" is not guarantee to 
have a debugger, usually with "toolchain" you mean {"binutils" + "c 
compiler"}, and you are missing the "libC" environment that is not 
necessary with the "bare board" aka "metal bare" aka "os-less" profile: 
i mean you can write by yourself your own libC and BSP. It's not 
difficult, it's really a piece of cake.


> it will be easier to start porting the application to this solution

an other problem is related to the fpga resources, for example the bram 
amount you have and could handle in your pfga.

the MIPS architecture is eating about 4-6 times the space of a CISC 
machine. Try to compile for 6809 for example! There is a pretty SoC made 
around 6809, it has a fully validated 6809 soft core, also there is

- gcc-6809 port, and it is working brilliant!
- binutils, the linker is tricky, it is not GNU compliant, it does not 
support common linker scripts, it does not produces an elf, it has a 
sort of binary output only, but it works!
- there is no gdb-6809, but there is great Windows program, aka 
noICE-6809 (you could get it for free), that is pretty able to use your 
elf's debugger-symbols (if you compile with -g flag on) in order to make 
you able to fully debug you C/assembly application.

but conceding instruction size, as i said MIPS is 4-6 time bigger than 
CISC 8 bit machines, that means you need larger bram in your FPGA, that 
means … we'd better implement an external SDRAM controller in order to 
have large ram to be used for .session {data, text}

this also means to have a fast upload link or an external SPI flash to 
bootstrap

in short: you can buy a real Atheros tiny router for 10 euro from china 
(i bought mine at 15 euro as the total, already shipped and VAT 
applied), it comes with an ASIC MIPS32-r2 core and it is already ready 
to work, it has soldered 64Mbyte of ram, a pretty DRAM controller, usb, 
ethernet, spi, uart, COP0 with timers, and also a JTAG port, the whole 
for 10 euro, so i think these things are killer applications about 
fpga-SoC … so people take effort to them instead of having troubles and 
consuming time developing all of these features in HDL (also, a good 
point is: WHY? does it makes sense ? Sometime it has no sense, i mean 
you'd better put an FPGA near to an ASIC CPU or SoC, instead of toying 
with HDL to have the whole embedded)


p.s.
also these chinese toys run linux, that is an other killer application 
for the most of guys, unfortunately =(

: Edited by User
Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
p.s.
guys, i am always talking about compiling/recompiling things on linux 
host, i do not want to deal with CyGwin, in short because i have found 
it more difficult and frustrating all the times i tried to compile 
things from GNU.

i trust virtual machines instead, for example putting a development 
linux mini root inside a VirtualBox Virtual machine, this way it will go 
easy for everyone

- download the virtual machine (hopefully it could be around 500Mbyte) 
with the development mini root inside (gcc, bintuilts, and so on, pretty 
ready out of the box)

- download the virtualizer, e.g. CoNix (1), or VirtualBox, or such a 
things

- run it from you host OS, about CoNix … well Windows Xp is the only 
choice , while VirtualBox runs on Windows, MacOSX, linux

- have fun


on linux you could prefer to mount the mini root, and in case it is 
possible to use a kernel service in order to have things 
loopback-mounted, something like mounting an image file (the virtual 
file system image, practically a file, used by the virtual machine) to a 
path instead of mounting a real device.



(1) CoNix is a virtualizing technology used by Analog Devices to put a 
linux kernel into a cooperative environment for Windows, that means you 
can have a virtual machine that shares files with your host NTFS, it 
also shares the lan, and makes you able to compile things inside a 
virtual filesystem (EXT3) full provided with all the LINUX environment 
(they are required by git, for example, NTFS has no native support for 
this, so CyGwin has to use ugly tricky workarounds) . Trust me, it is 
extremely cool if you want to mix Windows and Linux for your hobby 
purposes!

In my case i need Windows XP instead of linux, as native host OS, 
because i have a lot of Applications that are Windows-binary-only and 
they do no run inside Wine (especially if they need to access the 
hardware). So i am using this solution that is excellent! You also need 
a ssh-v2 terminal, plus a X11 environment: MobaXterm is the perfect 
solution for this, it pretty works under Xp, and it is free ! It is 
perfect to provide you a console to access the virtual machine 
throughout a Windows application.

: Edited by User
Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
- - - - - - - - - - - - - - -
Propeller 1 is now OpenSource
- - - - - - - - - - - - - - -


see this news, it provides a download zip package with inside Verilog 
sources of the Propeller v1, plus a pdf with instructions to put this 
SoftCore on Altera boards (e.g. De0 nano)

http://www.parallax.com/microcontrollers/propeller...

personally i do not like "propeller", i am writing this news in the hope 
it can help guys that are looking for a complete SoftCore eco-system, 
because in case you are wandering … Yes, it also comes with its 
toolchain and debug module!

: Edited by User
Author: abe (Guest)
Posted on:

Rate this post
0 useful
not useful
Michael Fischer wrote:
> Even it could be possible that all the MIPS and other softcores are
> only a playground in the academic research. But why does not exist
> a free FPGA/JTAG debug solution whereas more people has started with
> an own CPU?

There are quite a few solutions. You might want to check the MIPS 
compatible Mais processor or the Plasma core that has been out for 
years.
As you mention ZPU, there are a few quite well working implementations, 
they are described on the ZPU mailing list. I would actually consider 
the Zpuino or some Zealot based examples a pretty good ecosystem. 
However, I have the impression that some of you guys aren't tryin hard 
enough. In the free world of opensource, you've gotta read the source, 
luke.

Author: Michael Fischer (mifi)
Posted on:

Rate this post
0 useful
not useful
I have tried the Mais CPU for some month.
And it is not the right CPU for me at the current level.

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
> And it is not the right CPU for me at the current level.

exactly what is your purpose ? Have you ever considered an ASIC CPU 
instead of a pure FPGA SoC design ? In case have you have considered an 
ASIC CPU connected to a FPGA like the "mojo" boards, which also provides 
a native jtag, so you are fine with OpenOCD ? Which are your target 
applications, and exactly WHY you want a SoC ?

: Edited by User
Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
> I have the impression that

i have the impression that guys are attracted by the following things

"Connect GDB server to already running ARM micro program on-the-fly, 
When I was using Rowley CrossStudio, there was Attach button which 
connected debugger to already running program on the micro. Of course I 
know that Debug info in the project and binary on micro has to be in the 
sync. Now I use Eclipse, GCC and St-link GDB server, but question apply 
to other GDB servers like CoIDE GDB and OpenOCD. Is there same/similar 
functionality of attaching GDB/Debugger to already running code on micro 
with these tools? If I knew the exact term of this I would google it"

it seems an other point in favor of my thesis: it seems people want 
things already working just out of the box, and they are expecting a 
fpga-SoC to have these features already running, elseway they go for 
ARM-chips =(

it also seems no one remember the old-ages where there ware no ICE and 
jtag, for example m68k has nothing, and people used assembly monitor 
traps to debug throughout the serial port.

: Edited by User
Author: FPGAuser (Guest)
Posted on:

Rate this post
0 useful
not useful
Legacy My wrote:
> Also gdb-stub work has stalled for a few years (i
> can show it with my ATLAS board, it has gdb-stub in its firmware, it is
> NOT compatible with modern gdb's protocol) and one of the problems is
> that gdb serial protocol has evolved, but documentation didn't … what is
> around the web is crippled gdb-stub known that not all functions worked
> and will work.

First the gdb-stub is an important debug tool. You will find this stab 
in linux kernel, boot loaders and so on. I do not know how old are you. 
For not so long time the CPUs had no JTAG. Today each CPU has a JTAG.
 This is the reason why the GDB-stub work stalled.

You can very simple research the protocol


(gdb) set remote debug 1

displays the full transmission commands at your output.

The JTAG tool like OPENOCD receive gdb commands and make from this JTAG 
signals. This can be also frustration, when the timing is not correct or 
the JTAG server is for you CPU not full supported.

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
> The JTAG tool like OPENOCD receive gdb commands and make from this JTAG
> signals. This can be also frustration, when the timing is not correct or
> the JTAG server is for you CPU not full supported.

this is the reason of the idea of debug processor.



p.s.
Atmel is going to use a new proprietary debug-chip, it will go cheap and 
only compatible with AVR-studio, they want to use it for their new ARM 
boards and Arduino is planning to do the same with "Arduino/Zero".

: Edited by User
Author: Martin S. (strubi)
Posted on:

Rate this post
0 useful
not useful
>
> You have trashed a lot of my time

Wrong. You've used too much of my time. Definitely.


> you seem to use this forum to claim about your private business, perhaps
> this is useful for you, but how can be useful to others ?
>

I haven't read so much bullshit in a while...

>
>> Immature people like you are mainly the reason why I stopped handing out
>> valuable source code in the first place.
>
> Yeah, just the last one comment: i am really sure you have nothing of
> what you claimed "ready and working" as i hope you are just trolling to
> business doors, about "reason" you look like the ones-fellows that grab
> other's people work in order to close things into their dirty business,
> that means you take other's people effort for free! It is not correct.

FYI:
I've sent you plenty of info, including links to working code. If you 
had some decent amount of teeth, you would have gotten started with the 
docs and would have found out that it is far from being a 'brochure'. 
What do you do? You keep complaining and annoying me with private 
messages.
Sorry, boy, but this is just far from the least bit of netiquette, and 
you should simply accept that I don't opensource all of my work to 
nagging students. Also, your false allegations are inacceptable and you 
should be ashamed.
First, I don't do business with students, plus it definitely isn't 
dirty. Your tantrum babble would be rather close to defamation, if it 
wasn't so ridiculous.

>
> Btw, for such a reason, hope never see you again in my threads!

Well, I'm sorry you have to read this again, but you're behaving very 
immature. This is my last advice: Quit the pestering/trolling and start 
writing some code yourself.

Regards,

- Strubi

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
i do not want to deal with a troll like you

> Wrong. You've used too much of my time. Definitely.

yes, it is wrong: i haven't contacted you, YOU have contacted me, 
annoying then with something that looks like you want to sell to your 
customers

by emails (and also here) i have asked you 2 times about your code that 
is also not compiling and useless by its design (i was also told about 
this by other guys here in private).

Facts: four emails sent for the total, an useless brochure got.

You have claimed around the net about your "revolutionary debug method 
that should save us", so assuming what you have written could really be 
useful, i have asked for more informations and details, but, as the fact 
you believe you are a genius and other guys are simply "no-gooder", or, 
more probably, that they MUST be your customers in order to have 
informations, you have answered "go to the hell", that is really aligned 
with the OpenSource philosophy and it is also very polite and useful, 
man.

Let me say that people like you are THE reason why OpenSource is going 
wasted, especially if we consider that what happened looks like an 
evidence of your real intentions to open doors to your business, in 
order to sell things or to be a asked for consultant's jobs: you have 
nothing really working and you can't prove the opposite, while it could 
be easily proved that it is politically incorrect, especially when you 
try to use other people's work to close their effort into your business.

btw, i have things to develop, so you could really get my "bye bye" for 
free.

: Edited by User
Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
> (2)
> http://www.le.ac.uk/eg/embedded/PH.htm

two words about this topic: i have opened it asking about(2), but, as 
the fact "MIPS1 PH project v2's sources" are not available and as the 
fact i have been developing the debug-processor in a completely 
different way, about me, i assume this topic is concluded and in case i 
will open a new thread.

regards

: Edited by User
Author: Duke Scarring (Guest)
Posted on:

Rate this post
0 useful
not useful
Martin S. wrote:
> I haven't read so much bullshit in a while...
Me too. But Mr. Legacy adorning my killfile...

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
Duke Scarring wrote:
> Martin S. wrote:
>> I haven't read so much bullshit in a while...
> Me too

yes, let me explain others what happened, then you can go to the 
blacklist, too.

you have contacted me in private asking annoying things and hints about 
the development of my SoC, also you wanted hints about book and 
development material, and i kindly answered you also offering a free 
evaluation copy of the book i have bought (and payed) from Amazon! I 
have provide this book and support in the hope it could be helpful for 
you!

note, YOU have contacted me, then i asked about your comment about the 
MAIS, you answered not-resonable things like "it sux" without providing 
any valid reason, so i asked WHY you have find difficult and exactly 
WHAT you have found difficult -> that is useful for us in order to 
develop what could make you more comfortable

and at this point of the conversation, what was you answer, child ?

i asked these things 2 times, then i understood that you have found 
difficulties because the SoC comes without boot loader and no debugger, 
so you find difficulties because you have to re-synthetize everything 
and every time you change the firmware (that is a VHDL file).

that's UAU, very amazing from a guy who is claiming to be able to write 
an operating system port in his web site !

so the next question was: why haven't you code the boot loader by 
yourself instead proving us such a rants ? You answered "every body is 
able to write a boot loader", everybody is able, but you did't !

Talking with guys like you is a totally time trashed, i have written a 
lot of things here, and i am thinking it was time trashed, i do now want 
to trash my free time this way, i'd like useful conversation, i have 
been writing tools, i have been doing debugging, i have been using my 
free time also to help others.

btw, my disappoint is really over, since now, i have found a way to hide 
any notifications about this thread, i will never follow it, and the 
next time i will read such a shit i will remove my account from this 
forum!

: Edited by User
Author: Michael Fischer (mifi)
Posted on:

Rate this post
0 useful
not useful
Hello,

it was not Duke, I think you mean me?

>you have contacted me in private asking annoying things and hints about
>the development of my SoC, also you wanted hints about book and
>development material, and i kindly answered you also offering a free
>evaluation copy of the book i have bought (and payed) from Amazon! I
>have provide this book and support in the hope it could be helpful for
>you!
This is correct, I have deleted the files directly on the server and
bought the book from Amazon.

>note, YOU have contacted me, then i asked about your comment about the
>MAIS, you answered not-resonable things like "it sux" without providing
>a reason, so i asked WHY you have find difficult and exactly WHAT you
>have found difficult -> that is useful for us in order to develop what
>could make you more comfortable
This is correct, I have told you that I am not comfortable with the Mais
CPU compared to the LM32. I told you to test the "soc-lm32" project to
see the difference what I mean. With the soc-lm32 it is easier to get
the CPU up and running.

>i asked these things 2 times, then i understood that you have found
>difficulties because the SoC comes without boot loader and no debugger,
>so you find difficulties because you have to re-synthetize everything
>and every time you change the firmware (that is a VHDL file).

>that's UAU, very amazing from a guy who is claiming to be able to write
>an operating system port in his web site !

You have not understand my motivation. I have told before like YAGARTO.
It was created to simplify the use of an OpenSource ARM toolchain.

And this is my motivation here too. I want to create an OpenSource
MIPS packet which can be used easily. Therefore I am searching a
good point to start.

Best regards,
Michael

Author: Strubi (Guest)
Posted on:

Rate this post
0 useful
not useful
Legacy My wrote:
> next time i will read such a shit i will remove my account from this
> forum!

That's a heavy, even massive threat!

Happy to see that my reality isn't distorted, and seeing another classic 
proven again: blaming others of things that one keeps doing himself 
pairs with unlimited self-overestimation and no respect of boundaries.
I was already wondering, whether I'd really had done something 
'dirty'. But anyhow, let's close the psychology thread :-)
Seen enough of that on the MyHDL mailing list.

Author: Legacy My (Company: my) (legacy)
Posted on:

Rate this post
0 useful
not useful
this project is completed. If someone is interested, feel free to 
contact me

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [vhdl]VHDL code[/vhdl]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.