<xiangfu>
building the bitstream. seems it need some time still building
<xiangfu>
kristianpaul: Hi
<xiangfu>
from the email we need edit one line to disable the Video out. for fix the sound noise. can someone tell me which file which line I should edit. then I can build the bitstream and test in my MM1.
<xiangfu>
I have 0 experiment in VHDL :(
<aw>
xiangfu, when i selected 'Webpack' items , it seems will install: Webpack, ISE, ISE DS Common, EDK, Plan Ahead Analysis Tool.
<xiangfu>
aw: I just select the 'ISE Design Suite: system edition'
<xiangfu>
from the description: " ISE Design Suite: System Edition contains everything you need to do a complete system design."Â Â :)
<xiangfu>
'''contains everything'''. I don't know the detail. so just just select all
<aw>
finally it asked you for a license?
<aw>
xiangfu, 12.3 i installed 'Webpack' only. I remembered it needs a license.
<xiangfu>
it's will bring you to xilinx website. then you can got a license file
<aw>
xiangfu, yup
<aw>
xiangfu, yes, now the installer is asking me for license, so you stopped there? right?
<aw>
xiangfu, i think that I am now searching my 12.3 Free ISE Webpack license first. :-)
<xiangfu>
aw: no. I have success install. just follow the link. download the xilinx.lic file :)
<aw>
xiangfu, 13.1 detects my previous *.lic during last installed 12.3
<aw>
seems done successfully.
<lekernel>
hi
<wolfspraul>
hi
<aw>
lekernel, xiangfu hi, i think that we are ready for studying now. :-)
<lekernel>
ok, so you have the milkymist source and ise 13 installed?
<lekernel>
and sourced ise's settings32.sh?
<aw>
not yet..second
<xiangfu>
lekernel: I am using a 64bit system? I sourced settings32.sh? is that a problem?
<lekernel>
I don't know
<xiangfu>
I thought it's for host system.
<lekernel>
if it doesn't work try with settings64
<aw>
what I need to install for 'source'? i got 'sudo: source: command not found'
<xiangfu>
I have no problem with settings64. so I will just using settings64.
<lekernel>
aw: why sudo?
<aw>
don't know, i usually used 'sudo'..
<lekernel>
don't
<lekernel>
aw: is it ok? you have commands like impact, xst, ...?
<aw>
lekernel, i can run 13.1 impact, 'xst' don't know, never run before.
<lekernel>
ok, good
<lekernel>
so now go to the milkymist source
<lekernel>
and edit boards/milkymist-one/rtl/system.v
<lekernel>
ok, now open boards/milkymist-one/rtl/system.v
<lekernel>
and as you can see you have a line "module system(" followed by the list of all signals going in and out of the fpga
<lekernel>
this is the top level verilog file
<lekernel>
in this list you can see the vga signals are there:
<lekernel>
output vga_psave_n,
<lekernel>
output vga_hsync_n,
<lekernel>
output vga_vsync_n,
<lekernel>
output [7:0] vga_r,
<lekernel>
(...)
<xiangfu>
yes
<lekernel>
if you scroll down a bit you see that they go to a submodule called vga (around line 950)
<lekernel>
.vga_psave_n(vga_psave_n),
<lekernel>
.vga_hsync_n(vga_hsync_n),
<lekernel>
.vga_vsync_n(vga_vsync_n),
<lekernel>
.vga_r(vga_r),
<xiangfu>
yes
<lekernel>
so what you do is 1. disconnect those signals from the vga submodule
<lekernel>
so you delete all the lines that refer to the VGA signals from the vga submodule (from ".vga_psave_n(vga_psave_n)," to ".vga_sdc(vga_sdc)")
<lekernel>
and don't forget to remove the comma at the end of ".dcb_hit(dcb_hit),"
<lekernel>
2. ground those signals
<lekernel>
for each signal add a line
<lekernel>
assign vga_r = 0;
<lekernel>
or
<lekernel>
assign vga_psave_n = 1; (to set them to VCC)
<lekernel>
do this after the end of the vga submodule (i.e. immediately after the ");")
<lekernel>
once you have assigned the values you want to each VGA signal (0 or 1) go to the synthesis folder again and re-run make -f Makefile.xst and use urjtag
<lekernel>
btw if you want the FPGA not to drive a signal, use 1'bz, e.g. assign vga_sda = 1'bz;
<xiangfu>
xiangfu: ok. after add the 'assign' compile continue now :)
<nats`>
plop
<xiangfu>
Phase 9.8Â Â Global Placement ...
<xiangfu>
14mins passed. still running:Â Â Running physical synthesis...
<xiangfu>
finally. it's finished.
<xiangfu>
I still got the sound noise after the the serial output "RTEMS SHELL (Ver.1.0-FRC):/dev/console. Mar 14 2011. "
<xiangfu>
during the boot. the earphone is quiet. after RTEMS SHELL show up. I got noise in my earphone.
<xiangfu>
(like an old TV without any signal)
<lekernel>
ok. not very surprising i'd say, but at least you can check now
<xiangfu>
this noise is not very obvious  with my Desktop Speaker (2.1 speaker)
<lekernel>
yup... that's what I said... sometimes it's very obvious, sometimes you barely notice it
<lekernel>
but I don't know if this is because the noise amplitude actually varies of if it only depends on the response of speakers and environment
<aw>
xiangfu, mine is still running. you needs to listenning carefully the differences before/after we load a 'pull down' on RGB wires.
<lekernel>
we should get some scope measurements...
<lekernel>
or just measure on scope. don't listen
<aw>
yes, just listening probably hard to compare..
<aw>
if there's no bigger differences.
<xiangfu>
can I mute the audio in in RTEMS shell?
<lekernel>
no
<aw>
measuring on audio will be not like normal probing for scope. but I could only verify if there's obvious noise between 20Hz ~ 20Khz
<lekernel>
what's wrong with measuring noise on scope?
<aw>
it's some sort of frequency v.s. magnitude, my scope i think probably should not distinguish them. even they are all have same magnitudes
<aw>
lekernel, I'll try to compare both of them(different system.v) to probe. I am saying audio frequency response is hard to probe ..well..i'll try to measure during static state.
<aw>
'but I don't know if this is because the noise amplitude actually varies of if it only depends on the response of speakers and environment' >> agreed.
<aw>
so a better measurement is good for catching.  well..so far at least thanks you taught us though on modifying 'pull high & low' tasks.
<aw>
but this is not recommended to modify if people don't know pins definitions thorough.
<aw>
my 'system.bit' is created.
<aw>
yes, from my site results of only listening, they are the same loud noise. don't have clearly different though.
<kristianpaul>
ah, _out_ means vga :-)
<kristianpaul>
hi xiangfu, sorry i was sleeping at that time, but seems you managed already :-)
<aw>
lekernel,  i used speaker too. so yes, we _out_ & clarify that surely this is not caused by VGA RGB radiative/inductive noises influence.
<lekernel>
ok, so let's not modify anything on the vga layout in rc3
<aw>
well....but modification about that known issue on layout/routing is easy. you know. why not? ;-)
<aw>
lekernel, one question, after 'pull down' RGB submodules, why after RTEMS run i can still see monitor? won't it be frozen on screen?
<lekernel>
this just disconnects the FPGA I/O pins, the video controller is still running inside
<kristianpaul>
hmm
<aw>
hum? if they are all disconnected with FPGA I/O, why ADV7125 still have analog out to vga monitor? I still can not understand.
<aw>
i was supposed that we like to 'disconnect' RGB digital/parallel signals, so there's no any analog vga encoded to RGB components to vga connector. so I was thought I should not see any in monitor.
<lekernel>
aw: ah, you mean you still have a picture?!
<lekernel>
on the screen?
<lekernel>
no, this isn't normal
<lekernel>
how did you modify the system.v?
<lekernel>
and are you reloading correctly the new bitstream with urjtag?
<lekernel>
you've probably made a mistake somewhere. of course, this should completely prevent the monitor from displaying anything.
<aw>
yes, I forgot to ask xiangfu if he see nothing on vga monitor then.
<lekernel>
set vga_clk = 0
<lekernel>
not tri-state
<aw>
yeah..let me checked them again.
<lekernel>
this doesn't explain your problem, but this signal shouldn't float anyway
<lekernel>
I guess you are sending an old system.bit to the board
<aw>
but i run 'jtag' under ':~/milkymist/boards/milkymist-one/synthesis/build$ sudo jtag', ti should not be wrong. :-)
<aw>
well..check again...:-)
<lekernel>
and you have run "make -f Makefile.xst" before, right?
<aw>
yes.
<aw>
and export PATH before "make..--"
<aw>
making....now
<aw>
phase 9.8..
<xiangfu>
aw: the VGA monitor is black. nothing on it. I saw the boot progress on serial output
<aw>
xiangfu, must be mistakes on my making.
<aw>
i knew it now, once successfully on 'pld load system.bit' then screen is black.
<aw>
lekernel, i should carefully listen after done 'pld load system.bit' , right?
<aw>
no need to power cycle or i need ?
<lekernel>
no power cycle
<lekernel>
after pld load, your board should boot without any picture on vga
<lekernel>
(and if you measure the voltages on the adv7125 they should match the levels set in the verilog)
<aw>
okay so i have the same with serial out log with 'Minimac RX FIFO overflow' msg. then monitor is black and no more loud noise.
<Fallenou>
:(
<aw>
i turned maximum on my speaker without no audio input but still plug in audio cable in. second...checking.
<aw>
xiangfu, hope you confirm it again.
<lekernel>
if you get "minimac rx fifo overflow", it's a bug that prevents the board from booting
<lekernel>
you can't draw any conclusion if you get this message. just reboot until the message goes.
<lekernel>
you should only measure output noise when you get "RTEMS SHELL ..."
<aw>
um...seems my making steps is still somethings wrong. after i power cycle and shows up "RTEMS SHELL ..." but screen is still have.
<aw>
so yeah..no conclusion at all now.
<lekernel>
NEVER power cycle
<lekernel>
if you have to power cycle, you're doing it wrong
<aw>
um..so my steps of making was somewhere wrong already.
<methril_work>
nice MMOne load & hack session
<lekernel>
aw: apply power, run urjtag, type "pld load", and it boots your new bitstream
<lekernel>
done
<lekernel>
don't power cycle, don't touch the buttons
<aw>
umm..i was wrong on touching the buttons and power cycle though.
<aw>
okay..so before/after 'pld load system.bit'...is the same.
<aw>
done. tks for teaching.
<lekernel>
it's the same?
<lekernel>
can you ask xiangfu? he got it to work
<methril_work>
if i`ll catch it properly load is like openocd/gdb load command (it loads the "sw" into the memory, but you loose the changes if you power cycle)
<lekernel>
yeah that's what it does
<aw>
lekernel, i'll confirm with xiangfu tomorrow. I got the same results.
<lekernel>
aw: but did the VGA out go off or not?
<aw>
lekernel, go off surely.
<lekernel>
ah, ok!
<lekernel>
well, good, then
<lekernel>
everything normal :)
<aw>
methril_work, i have no any idea on s/w, but today yes, thanks lekernel to let us confirm this experiments initially