Rev |
Log message |
Author |
Age |
Path |
242 |
AS1 produced an unnoticed delay, the compiler geenerated an extra stage..... so a delay constant was added to sync this extra stage with the operation via ssync_chain |
jguarin2002 |
4417d 01h |
/raytrac/branches/fp_sgdma/ap_n_dpc.vhd |
236 |
Tunnning delay added to q0 queue |
jguarin2002 |
4418d 07h |
/raytrac/branches/fp_sgdma/ap_n_dpc.vhd |
235 |
Tunnning delay added to q0 queue |
jguarin2002 |
4418d 07h |
/raytrac/branches/fp_sgdma/ap_n_dpc.vhd |
230 |
RC 1.0 Previous rev(228), is functional and even more than this one, but is bigger and is for debugging |
jguarin2002 |
4424d 10h |
/raytrac/branches/fp_sgdma/ap_n_dpc.vhd |
229 |
Total RtEngine Hardware, BUT, problems with interconnection... perhaps theres a problem with long path on ssumando5 |
jguarin2002 |
4425d 10h |
/raytrac/branches/fp_sgdma/ap_n_dpc.vhd |
228 |
Fixed a BUG where big differences betweeen exponents difference suffered from miss-signedness because of the width of the result was 1 bit narrower, and still its highest significant bit was taken as the sign, in result big differences in where taken as negative results... leading to situations like A+0=0 cause the exponent chosen as the big one was the zero's (-127) leading to an unexpected 0 in the result. The bug was fixed by correcting the signedness of the operation and making the result less narrower in one bit. |
jguarin2002 |
4427d 03h |
/raytrac/branches/fp_sgdma/ap_n_dpc.vhd |
220 |
ap_n_dpc.vhd es el RTL que integra DataPathControl y ArithPipeLine |
jguarin2002 |
4436d 18h |
/raytrac/branches/fp_sgdma/ap_n_dpc.vhd |
219 |
RayTrac: Non tested and witouh TSE |
jguarin2002 |
4436d 20h |
/raytrac/branches/fp_sgdma/dpc.vhd |
212 |
DPC changes\n\n\t+ established the DCS system rather than the UCA definitively\n\t+ Rather than usign 4 result queues now theres just a single one, of course 4 times wider, this was made to gain simplicity when writing and reading the RTL description that adapts this 4/3/1 word wide result buffer output into a 1 word wide result buffer input\n\t+ Added the Q1 queue to syncrhonize magnitude and normalization ops, managing them to enter at the sime tame rather than different times, formerly it was implemented by setting the normalization and magnitude results into the results buffers at 25th beat and 20th beat respectively, now both results enter into THE SINGLE RESULT QUEUE at 25th beat. This change also forces that Dot product operation to use the Q1 hardware and entering also at beath 25th into the result queue, it could be done in an earlier beatt (in fact in the 19th) but multiplexation logic would have to be added. |
jguarin2002 |
4437d 15h |
/raytrac/branches/fp_sgdma/dpc.vhd |
204 |
Working towards a DMA oriented RayTRac |
jguarin2002 |
4449d 04h |
/raytrac/branches/fp_sgdma/dpc.vhd |
198 |
Check out for the best out for the best organization so the datapath does not consume to many logic cells |
jguarin2002 |
4465d 10h |
/raytrac/branches/fp_sgdma/dpc.vhd |
196 |
raytrac+sg_dma+raytrac. Step One, the DPC is transformed. Now there are five instructions (check the design document), theres no full queue sync event, there are only four result queues and only 3 add fp 32 b adders rather than 4. Even it seems like a reduction has taken place, decodification efforts take place when decoding multiplexation from arithmetic blocks towards the resulting queues |
jguarin2002 |
4478d 23h |
/raytrac/branches/fp_sgdma/dpc.vhd |
179 |
light change on code readbility for Datapath Control hardware description hdl file |
jguarin2002 |
4506d 07h |
/dpc.vhd |
176 |
Little changes on full result queue signals codification in order to fix a potential bug that havent beed detected at the time of the change in the code |
jguarin2002 |
4541d 20h |
/dpc.vhd |
175 |
Fixed a problem on the writing signal of results queue 5,6 and 7. The error was detected just right when a calculated normalized vector was about to be written in the results queues 5 6 and 7 and the write signals of those were not activated (it would remain in 0), after checking what was the problem, a codification bug was spotted. |
jguarin2002 |
4541d 20h |
/dpc.vhd |
171 |
After some raytrac simulation result analysis, some bugs were detected on the decodification of several datapaths. Corrections were done and tested |
jguarin2002 |
4541d 20h |
/dpc.vhd |
167 |
Corrections on the moment the dot product and normalization queues are "rd_ack\'ed", they were a cycle earlier than they should causing pipeline desync |
jguarin2002 |
4544d 10h |
/dpc.vhd |
163 |
dpc: Signals to eval in functional simulatio. Fix on the codification of the sign applied into the arithmetic block depending on the UCA code of the instruction being excuted. Also a correction was done on the decodification of the result queues write signals. A correction applied on the decodification of the interruptions generated due to full queues. RayTrac: A signal to decode the sign that goes into the addition operations was made as long with its combinatorial operation to calculate it. Fadd32: Signals to eval in functional simulation. An important bug was fixed when decoding the shift to normalize the mantissa of the float number with the minor exponent, that was causing a misscalculation of the normalized mantissa. Arithpack: Formatting of the instruction at function ap_format_instruction fixed due to a change in the opcodes of the unary instructions. |
jguarin2002 |
4546d 09h |
/dpc.vhd |
161 |
Changes for the sake of the firsts simulation tracking results |
jguarin2002 |
4548d 00h |
/dpc.vhd |
160 |
Corrections derived from simulation debugging |
jguarin2002 |
4552d 17h |
/dpc.vhd |