| Rev |
Log message |
Author |
Age |
Path |
| 243 |
The Registers BASE+1, BASE+2, BASE+3 are used now for debugging purposes |
jguarin2002 |
4821d 07h |
/raytrac/branches/fp_sgdma/ |
| 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 |
4821d 07h |
/raytrac/branches/fp_sgdma/ |
| 241 |
fmul32 x 6 multipliers wide |
jguarin2002 |
4822d 03h |
/raytrac/branches/fp_sgdma/ |
| 240 |
last minute correction |
jguarin2002 |
4822d 07h |
/raytrac/branches/fp_sgdma/ |
| 239 |
wide multiplicator added to avoid optimization |
jguarin2002 |
4822d 07h |
/raytrac/branches/fp_sgdma/ |
| 238 |
wide multiplicator added to avoid optimization |
jguarin2002 |
4822d 07h |
/raytrac/branches/fp_sgdma/ |
| 237 |
corrected errors in raytrac.vhd |
jguarin2002 |
4822d 09h |
/raytrac/branches/fp_sgdma/ |
| 236 |
Tunnning delay added to q0 queue |
jguarin2002 |
4822d 12h |
/raytrac/branches/fp_sgdma/ |
| 235 |
Tunnning delay added to q0 queue |
jguarin2002 |
4822d 12h |
/raytrac/branches/fp_sgdma/ |
| 234 |
raytrac update nothing major |
jguarin2002 |
4823d 12h |
/raytrac/branches/fp_sgdma/ |
| 233 |
raytrac sopc component updated |
jguarin2002 |
4823d 12h |
/raytrac/branches/fp_sgdma/ |
| 232 |
raytrac sopc component updated |
jguarin2002 |
4823d 12h |
/raytrac/branches/fp_sgdma/ |
| 231 |
nfetch address counter implemented in a whole register for convinience |
jguarin2002 |
4823d 13h |
/raytrac/branches/fp_sgdma/ |
| 230 |
RC 1.0 Previous rev(228), is functional and even more than this one, but is bigger and is for debugging |
jguarin2002 |
4828d 15h |
/raytrac/branches/fp_sgdma/ |
| 229 |
Total RtEngine Hardware, BUT, problems with interconnection... perhaps theres a problem with long path on ssumando5 |
jguarin2002 |
4829d 15h |
/raytrac/branches/fp_sgdma/ |
| 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 |
4831d 08h |
/raytrac/branches/fp_sgdma/ |
| 221 |
The change in sqrt and inv is about the path of the files with the data memory. dpc has been changed by ap_n_dpc and there was an error on RayTrac related to the load sync chain: the loading of Dot product Operation was being carried out as if it was an unary operation rather than a two operands operation |
jguarin2002 |
4840d 22h |
/raytrac/branches/fp_sgdma/ |
| 220 |
ap_n_dpc.vhd es el RTL que integra DataPathControl y ArithPipeLine |
jguarin2002 |
4840d 23h |
/raytrac/branches/fp_sgdma/ |
| 219 |
RayTrac: Non tested and witouh TSE |
jguarin2002 |
4841d 01h |
/raytrac/branches/fp_sgdma/ |
| 218 |
Raytrac : NS_JULI_DSF_ASM_DMA_120812_18081 : SOPC Library TCL scrip, load it into the Altera Project |
jguarin2002 |
4841d 05h |
/raytrac/branches/fp_sgdma/ |
