gmane.comp.multimedia.milkymist.devel

Re: Mibuild : Support for Xilinx Vivado toolchain

Sébastien Bourdeauducq — 2013-05-20T16:23:49

Could not test, I don't have a 7 series board around yet.

Re: Mibuild : Support for Xilinx Vivado toolchain

Werner Almesberger — 2013-05-20T16:23:19

Did the output actually work ?

- Werner
_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist< at >Freenode

Re: Milkymist SoC on Nexys3 board

Sébastien Bourdeauducq — 2013-05-20T16:02:43

Be careful that the BIOS uses that SRAM for the stack and some variables 
already.

Milkymist SoC on Nexys3 board

Yann Sionneau — 2013-05-20T16:03:04

Hello,

A minimalistic version of Milkymist-ng SoC [0] can be run on the Nexys3 
FPGA board [1].
The SoC runs at 100 MHz (on-board oscillator).
The SoC is a very basic cut-down:

- LM32
- Timer
- Uart
- On-chip ROM (32 KB) and SRAM (16 kB) (to hold the BIOS code and allow 
it to run)

The on-board PSRAM (Pseudo Static DRAM, basically DRAM you can use like 
SRAM) and "flash" PCM are not used.
It seems there is no way to program the PCM "flash" under Linux, so the 
basic idea of this mini SoC is to run the BIOS from the on-chip ROM and 
then serialboot the real application (NetBSD kernel for instance) using 
flterm on the PC side.

Of course, in order to even think about running NetBSD kernel on such a 
device, a PSRAM controller is needed to access the 16 MB (which should 
be enough according to Radoslaw Kujawa) of on-board PSRAM.

For now it just runs a basic BIOS, you can access the BIOS prompt using 
the UART.
Next step would be to try to serialboot a small application (small 
enough to fit into the 4 kB S

Re: Mibuild : Support for Xilinx Vivado toolchain

Sébastien Bourdeauducq — 2013-05-19T22:47:09

I tried implementing a LED blinker with one of the first Vivado 
versions, and concluded it was unusable bloatware after it took more 
than 10 minutes to compile it.

Strangely enough, I tried synthesis+P&R of LM32 more recently, and it 
completed just under a minute. I don't have my Vivado install anymore so 
I can't quickly test your design, but will do that when I have some 
spare time.

Sebastien

Mibuild : Support for Xilinx Vivado toolchain

Florent Kermarrec — 2013-05-19T22:33:08

Hi,

in case someone want to test VIVADO with mibuild, here is the vivado
support for mibuild : http://git.io/jaBQVg

design flow is tested with milkymist-ng port on the KC705 but I'm still
trying to understand the results I have:

While it supposed to be "up to 4X faster than alternative solution", 2013.1
version takes 80 minutes to generate the bitstream where ISE takes only 10
minutes...

It's maybe something specific with my configuration or some verilog code
that is not correclty implemented with VIVADO, but I don't have too much
time now to understand what is going on and will probably keep using ISE...

Regards,

Florent

Re: preorders for the first Mixxeo prototypeboards

Sébastien Bourdeauducq — 2013-05-18T20:35:58

Due to the design files taking longer than I had thought, this is 
extended until June 5th.

Check out the Swedish VJ Union article posted today:
http://www.vjunion.se/2013/05/the-mixxeo-hdmidvi-mixer-project/

Sebastien

Re: NetBSD kernel stack

Radoslaw Kujawa — 2013-05-18T15:34:55

Hi all.

On 18 May, 2013, at 15:50 , Yann Sionneau <yann.sionneau-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


Since I'm not an expert on context switches and stack pointers, I've consulted another developer. As I've mentioned before, it would be the best if you posted technical questions to tech-kern< at > list. This way you'll get the answer fastest and from most competent people.


Each LWP (lightweight process) has a context associated with it that includes the stack pointer. 


The kernel has many stack pointers (one per LWP), but when doing context switch we save only the current stack pointer.


ctxsw - context switch


Yes, certainly.


PCB is "process control block", but in NetBSD it's more of an lightweight process control block. It means that there will be one PCB per LWP, _not_ per process.

PCB is defined as MD struct in:
src/sys/arch/*/include/pcb.h

That's becuase Wikipedia's description doesn't seem to take LWPs into account. Quoting the kernel documentation:

"LWP or lightweight process corr

Re: NetBSD port to Milkymist

Yann Sionneau — 2013-05-18T14:07:01

Hi!

Le 18/05/13 00:08, Radoslaw Kujawa a écrit :
Wow, those seem like real power beasts :) I didn't know ARMv7 could have 
64 bits data path to DRAM, nice!
Great! Thank you :)
Ok!
Yes that's where I got it from ;)
No problem at all! Everyone is a noob until he's a guru someday ;)
A bit of buffering should suffice to connect a PSRAM controller directly 
as a wishbone (the internal bus interconnect we use) slave.
Seems like a very nice tool!
Ineed I guess this kind of tool is really necessary when you have a lot 
of "versions" (or ports) of a given software and not so much maintainers 
or time to check it builds for all possible configurations!
Well, it does not sound *that* insane since I don't think we can do 
better for now.
I tried to ask around if anyone would have a Nexys 3 for me to borrow 
but it seems no-one has it.
Moreover I asked a few people if they would have extra Milkymist One 
board to lend you: nobody has extra M1. We unfortunately cannot provide 
you with a M1 :/ (I only have 1)
Qemu could

NetBSD kernel stack

Yann Sionneau — 2013-05-18T13:50:17

Hi Radoslaw and Milkymist fellows,

I have been struggling with the kernel stack pointer for a few days now, 
I could keep digging in the source code even more but since you offered 
you help I wanted to ask you if you would know how the NetBSD kernel (at 
least the ports you know) handle the kernel stack pointer.

To be more clear about what I want to understand, when there is an 
exception (say a page fault) here is what I need to do:

0°) LM32 CPU ensures interrupts are masked and MMU is turned OFF, it 
then gives control to the corresponding exception vector
1°) I need to save the registers somewhere
      a°) I use a trick where I use r0 (which should always be 0) to 
address a static memory region (with MMU off), I can then write in a 
trapframe structure all the registers r0 to r31 and then I'm done with 
saving them and I can do whatever I want without fearing to overwrite a 
value needed to restore context.
      b°) I check if I was in kernel context or user space context
         - If I was in

Qemu + MMU

Yann Sionneau — 2013-05-18T12:56:23

Hi,

What's the status of Qemu support of the LM32 MMU?
Is it in sync with what's commited in milkymist/lm32 GitHub repository?

Cheers :)

Fwd: Re: NetBSD port to Milkymist

Yann Sionneau — 2013-05-18T12:27:21

FYI the discussion about a possible Nexys 3 port of Milkymist SoC.

Does anyone have a Nexys 3 board that he could lend me for a few months?

I can pay for both way shipping costs via bank transfer payment :)

Cheers !

-------- Message original --------
Sujet: Re: NetBSD port to Milkymist
Date : Sat, 18 May 2013 00:08:54 +0200
De : Radoslaw Kujawa <radoslaw.kujawa-9hU5SXCXPvqsTnJN9+BGXg< at >public.gmane.org>
Pour : Yann Sionneau <yann.sionneau-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>



Hi!

On 17 May, 2013, at 20:48 , Yann Sionneau <yann.sionneau-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


I've googled a bit and found a lot of documentation related to LM32 and Milkymist. It's much better than I expected.


Indeed, I know something about this too. I have to admit that I never did any NetBSD port from scratch, but I wrote various low level components and drivers. You can check the list on my wiki page:
http://wiki.netbsd.org/users/rkujawa/

Now I am working on integrating NetBSD port to Marvell's Armad

Fwd: NetBSD port to Milkymist

Yann Sionneau — 2013-05-18T12:25:12

FYI


-------- Message original --------
Sujet: NetBSD port to Milkymist
Date : Fri, 17 May 2013 14:20:05 +0200
De : Radoslaw Kujawa <radoslaw.kujawa-9hU5SXCXPvqsTnJN9+BGXg< at >public.gmane.org>
Pour : yann.sionneau-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org



Hello.

Great job with porting NetBSD to the Milkymist and LM32!

I know next to nothing about Milkymist and LM32, but as NetBSD developer I can help you integrating the port into our source tree (once the port is ready). To ease the integration process, please use the latest development version of NetBSD (HEAD branch) instead of 6.x for your development work.

Also, I wonder how difficult it would be to run LM32 core on my Digilent Nexys 3 board? Having some hardware that can actually run it would make testing much easier for me ;).

Re: A new NetBSD port is coming (WIP)!

Yann Sionneau — 2013-05-17T18:32:11

Le 17/05/13 13:09, Greg Troxel a écrit :
Hey, thanks :)

I forgot to mention my nickname on IRC is 'Fallenou' sometimes with an 
'_' at the end.
You can talk to me on #NetBSD or on #milkymist which is the official IRC 
channel of the Milkymist project.

Regards,

Yann Sionneau
aka Fallenou

A new NetBSD port is coming (WIP)!

Yann Sionneau — 2013-05-17T09:54:27

Hello NetBSD guys,

First, sorry for cross-list posting, I didn't really know where this 
e-mail belong to.

Here is a small notice to let you know that I am in the process of 
adding support for the LatticeMico32 CPU [0] and the Milkymist SoC [1] 
to NetBSD 6 kernel.

LatticeMico32 (LM32) is an Open Source softcore (CPU which runs as 
gateware inside a FPGA) developed by Lattice Semiconductor.
LM32 can be used on several FPGA models from several FPGA vendors 
(Xilinx (Virtex 4, Spartan 3, Spartan 6 etc) Lattice, Altera (DE0 board) 
and maybe more).
Originally this CPU did not have any kind of MMU. Last year I developed 
an MMU for LM32 with the help of the Milkymist community (and a lot of 
help from Michael Walle in particular).

The LM32 softcore CPU is used in the Open Source Hardware Milkymist SoC 
which is the main component of the Milkymist One board [2].

For now, the Milkymist SoC/board runs an embedded OS (RTEMS) and is able 
to run ucLinux (no-mmu) as well.

The first goal of my work is to make Ne

Re: Patch to fix a simple stale test bench

Sébastien Bourdeauducq — 2013-05-15T10:52:45

Cool, thanks for proposing. Will think of that!


Resizing with bilinear filtering is definitely possible on a Slowtan-6 
FPGA (the legacy SoC TMU already does that). Full pixel shader with 
arbitrary bilinear sampling I'll have to think of it.

Good performance is difficult, especially as you are supposed to output 
more than one pixel per system clock cycle if you want a decent 
resolution. Remember that each output pixel requires accessing 8 input 
pixels just for mixing 2 sources with bilinear filtering, so the memory 
system becomes very challenging especially with the ludicrous routing 
delays of my favorite FPGA.


The current code handles that already. It's even tested (60/72/75 -> 
60Hz) and works :)

Sebastien

Re: Patch to fix a simple stale test bench

2013-05-15T10:45:27


I've wanted dynamic generation of EDID for a while. Failed to find any code outside of proprietary applications. Coding it myself from the VESA spec document has always been put-off with other things more important.

If you have / find / want to code the dynamic generation of EDIDs, thats something I could concretely collaborate around.


Which was part of my question: is the M1 hardware capable and/or could the pixel shader approach be implemented now in limited form as a base for future such goodness as billinear filtering etc.

Note: differing frame rates are also going to require temporal sampling or other such sophistication.

Re: Patch to fix a simple stale test bench

Sébastien Bourdeauducq — 2013-05-15T10:27:57

Yes, using EDID first to force some resolution at the inputs. The FPGA 
can control the hotplug detect pins of the input ports. So it would work 
as follows:
1) the Mixxeo inputs ports appear completely disconnected to the two sources
2) the Mixxeo output is connected, the M1 reads the EDID and sets a 
screen resolution
3) the Mixxeo rewrites the EDID of the inputs to make the two sources 
have the same resolution as the output
4) the Mixxeo enables the hotplug detect of the inputs and the sources 
detect the new connections, read the EDID, and start generating video

It is much simpler than good resizing with bilinear filtering, which 
could come later with a firmware upgrade.

M3 platform is also for later. Mixxeo is still based on the M1 design.

Sebastien

Re: Patch to fix a simple stale test bench

2013-05-15T10:08:22


Hmmm.

The arbitrary sampling is there for 
- basics: resizing inputs, handling mismatched aspect ratios
- advanced: display wall controller, soft edge blending, warping for projection mapping
- crazy: art, ie. as d-fuse we do a lot of 2D cut-up and manipulation of sources live with a load of openGL patches I've written.

And I'll be upfront that my interest is in what could be done with the M^3 platform and a software definable pipeline between multiple inputs and outputs.

Which leads to the questions - is the present M1 implementation limited to 1:1 pixel mapping between inputs and output, and is there an alternative route you were intending to implement that doesn't have the pixel shader with sampler approach?

Re: Patch to fix a simple stale test bench

Sébastien Bourdeauducq — 2013-05-14T22:24:45

Hmm, that might work with a pipeline like this:

"PFPU" generating addresses -> memory controller -> "PFPU" processing 
the data -> video DAC

plus a compiler that splits the code into address generation and 
processing parts. Memory addresses that depend on memory content cannot 
work with an architecture like that, but it should not be a problem for 
many graphics processing algos :)

(Of course, "memory controller" is an oversimplification, we'll need 
multi-ported prefetch caches and what not in order to obtain halfway 
decent performance from the Slowtan-6. This paper describes an 
interesting solution: 
https://graphics.stanford.edu/papers/texture_prefetch/)

Sebastien

Re: Patch to fix a simple stale test bench

2013-05-14T19:34:30

The ideal is an bare bones equivalent of an OpenGL pixel shader, ie.

- A function is executed for every output pixel.
- This function has a sampler available to bring in arbitrary pixels from sources
- This function can do some basic RGB maths

(and, props for getting this far!)

Toby

tbz::spk // mobile mail

On 14 May 2013, at 17:47, Sébastien Bourdeauducq <sebastien.bourdeauducq< at >lekernel.net> wrote:

_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist< at >Freenode